Wicket Release Plans for 1.5

[Corbin, James-2]

I noticed that 1.5 maintenance releases are available.  Can someone
speculate on the release time frame for 1.5?

 

We are contemplating an upgrade from 1.4.1 and want to avoid upgrading
to 1.4.3 and then 1.5 immediately after that.

 

Regards,

J.D.

 

[martin-g]

it will take some time for 1.5 final
I'll recommend to use 1.4.x for the next several months

El jue, 29-10-2009 a las 09:55 -0600, Corbin, James escribió:

> I noticed that 1.5 maintenance releases are available.  Can someone
> speculate on the release time frame for 1.5?
>
>  
>
> We are contemplating an upgrade from 1.4.1 and want to avoid upgrading
> to 1.4.3 and then 1.5 immediately after that.
>
>  
>
> Regards,
>
> J.D.
>
>  
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[dtoffe]

    Besides, it would be very interesting to know what changes and new features are planned.

Cheers,

Daniel

Corbin, James-2 wrote:

I noticed that 1.5 maintenance releases are available.  Can someone
speculate on the release time frame for 1.5?

We are contemplating an upgrade from 1.4.1 and want to avoid upgrading
to 1.4.3 and then 1.5 immediately after that.

Regards,

J.D.

[igor.vaynberg]

the focus of this release is to rewrite url and page handling. the
focus is on flexibility and pluggability as well as simplification of
use to the end user.

the other major feature is the markupfragment implementation, which
will allow users access to the markup the component is attached to,
possibly, at a time earlier then render time.

other then that there will probably be smaller features that will not
go into 1.4.x because they require an api break.

-igor

On Thu, Oct 29, 2009 at 10:38 AM, dtoffe <dtoffe@...> wrote:

>
>    Besides, it would be very interesting to know what changes and new
> features are planned.
>
> Cheers,
>
> Daniel
>
>
> Corbin, James-2 wrote:
>>
>> I noticed that 1.5 maintenance releases are available.  Can someone
>> speculate on the release time frame for 1.5?
>>
>> We are contemplating an upgrade from 1.4.1 and want to avoid upgrading
>> to 1.4.3 and then 1.5 immediately after that.
>>
>> Regards,
>>
>> J.D.
>>
>>
>
> --
> View this message in context: http://www.nabble.com/Wicket-Release-Plans-for-1.5-tp26115807p26117574.html
> Sent from the Wicket - User mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[dtoffe]

    Thanks for your answer,

Daniel

igor.vaynberg wrote:

the focus of this release is to rewrite url and page handling. the
focus is on flexibility and pluggability as well as simplification of
use to the end user.

the other major feature is the markupfragment implementation, which
will allow users access to the markup the component is attached to,
possibly, at a time earlier then render time.

other then that there will probably be smaller features that will not
go into 1.4.x because they require an api break.

-igor

On Thu, Oct 29, 2009 at 10:38 AM, dtoffe <[e-mail]> wrote:
>
>    Besides, it would be very interesting to know what changes and new
> features are planned.
>
> Cheers,
>
> Daniel
>

[Frank Silbermann]

I was discussing glue for composing reusable panels into web pages on
the blog of Erik van Oosten
(http://blog.jteam.nl/2009/09/16/wicket-dos-and-donts/).

I told him that my approach had been to create an abstract base page
that constructs the common elements while leaving place-holders for
page-specific panels by defining methods such as:

        abstract Panel createUpperLeftPanel (String wicketID);
        abstract Panel createLowerRightPanel(String wicketID);

and having the base page's constructor say things like:

        Panel p1 = createUpperLeftPanel("a_wicket_id");
        add(p1);
        ...
        Add( createUpperRightPanel("another_wicket_id") );

The child page's contribution would be the implementation of the
abstract methods.
 
I explained that I preferred this to mark-up inheritance because I could
add to the base page in any number places (not just one place), the
compiler would tell the child-page writer exactly what panels were
needed, and most importantly, no additional mark-up whatsoever would
need to be associated with any of the child pages.  (Panel classes used
by the child page would of course have their associated mark-up.)  

Eric and others explained what a bad idea it is for constructors to call
overridable methods -- they execute before the child-page's properties
have been set.  I usually got away with this, but I admit I was burnt a
few times.  Recently, I wondered whether there might be a simple fix for
the constructor-calls-overridable-method problem, such as:

(a) Move the base page's component tree construction out of the
constructor, and put it into the method:

        private void assembleComponents() {
                ...
        }

(b) Add the property:

        private boolean componentsAssembled = false;

(c) Override as follows to construct the component tree after the class
constructors finish:

        @Override
        void onBeforeRender() {
                if ( !componentsAssembled ) {
                        assembleComponents();
                        componentsAssembled = true;
                }
                super.onBeforeRender(); // Or whatever else is needed
        }

Then component construction would wait until the properties in both the
parent and the subclass had been set.  I'd no longer have the problem
associated with calling abstract methods from the constructor.

Do you see any disadvantages to this approach? Is there a more
appropriate hook upon which to hang my base page's component-tree
assembly?

If it _is_ a good approach, is there any reason the Wicket designers
chose not to create an overrideable method in the Component class that
is called just once after constructors terminate, and tell developers
that this is where the component tree should be created?

/Frank

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Pedro H. O. dos Santos]

Hi Frank, about your final question, the ListView class is an component that
partially use you approach: his children components are created on abstract
method implementations. This abstract is called due an condition that test
for reuseItems and size properties. And this call is originated in
onBeforeRender method.

On Thu, Oct 29, 2009 at 4:50 PM, Frank Silbermann <
frank.silbermann@...> wrote:

>
> I was discussing glue for composing reusable panels into web pages on
> the blog of Erik van Oosten
> (http://blog.jteam.nl/2009/09/16/wicket-dos-and-donts/).
>
> I told him that my approach had been to create an abstract base page
> that constructs the common elements while leaving place-holders for
> page-specific panels by defining methods such as:
>
>        abstract Panel createUpperLeftPanel (String wicketID);
>        abstract Panel createLowerRightPanel(String wicketID);
>
> and having the base page's constructor say things like:
>
>        Panel p1 = createUpperLeftPanel("a_wicket_id");
>        add(p1);
>        ...
>        Add( createUpperRightPanel("another_wicket_id") );
>
> The child page's contribution would be the implementation of the
> abstract methods.
>
> I explained that I preferred this to mark-up inheritance because I could
> add to the base page in any number places (not just one place), the
> compiler would tell the child-page writer exactly what panels were
> needed, and most importantly, no additional mark-up whatsoever would
> need to be associated with any of the child pages.  (Panel classes used
> by the child page would of course have their associated mark-up.)
>
> Eric and others explained what a bad idea it is for constructors to call
> overridable methods -- they execute before the child-page's properties
> have been set.  I usually got away with this, but I admit I was burnt a
> few times.  Recently, I wondered whether there might be a simple fix for
> the constructor-calls-overridable-method problem, such as:
>
> (a) Move the base page's component tree construction out of the
> constructor, and put it into the method:
>
>        private void assembleComponents() {
>                ...
>        }
>
> (b) Add the property:
>
>        private boolean componentsAssembled = false;
>
> (c) Override as follows to construct the component tree after the class
> constructors finish:
>
>        @Override
>        void onBeforeRender() {
>                if ( !componentsAssembled ) {
>                        assembleComponents();
>                        componentsAssembled = true;
>                }
>                super.onBeforeRender(); // Or whatever else is needed
>        }
>
> Then component construction would wait until the properties in both the
> parent and the subclass had been set.  I'd no longer have the problem
> associated with calling abstract methods from the constructor.
>
> Do you see any disadvantages to this approach? Is there a more
> appropriate hook upon which to hang my base page's component-tree
> assembly?
>
> If it _is_ a good approach, is there any reason the Wicket designers
> chose not to create an overrideable method in the Component class that
> is called just once after constructors terminate, and tell developers
> that this is where the component tree should be created?
>
> /Frank
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>
>

--
Pedro Henrique Oliveira dos Santos

[John Krasnay]

Rather than having the base class "pull" in components from the subclass,
recently I've been tackling this kind of problem by creating RepeatingViews in
the base class and letting subclasses "push" components in by adding to the
repeating view:

    <div class="leftNav">
      <div wicket:id="leftNavChild" class="leftNavChild"></div>
    </div>

    public class BasePage extends WebPage {
        private RepeatingView leftNavChildren;
        public BasePage() {
            add(leftNavChildren = new RepeatingView("leftNavChild"));
        }
        protected void addLeftNavChild(Component child) {
            leftNavChildren.add(child);
        }
        protected String newLeftNavChildId() {
            return leftNavChildren.newChildId();
        }
    }

    public class SubPage extends BasePage {
        public SubPage() {
            addLeftNavChild(new MyNavPanel(newLeftNavChildId()));
        }
    }

jk

On Thu, Oct 29, 2009 at 01:50:06PM -0500, Frank Silbermann wrote:

>
> I was discussing glue for composing reusable panels into web pages on
> the blog of Erik van Oosten
> (http://blog.jteam.nl/2009/09/16/wicket-dos-and-donts/).
>
> I told him that my approach had been to create an abstract base page
> that constructs the common elements while leaving place-holders for
> page-specific panels by defining methods such as:
>
> abstract Panel createUpperLeftPanel (String wicketID);
> abstract Panel createLowerRightPanel(String wicketID);
>
> and having the base page's constructor say things like:
>
> Panel p1 = createUpperLeftPanel("a_wicket_id");
> add(p1);
> ...
> Add( createUpperRightPanel("another_wicket_id") );
>
> The child page's contribution would be the implementation of the
> abstract methods.
>  
> I explained that I preferred this to mark-up inheritance because I could
> add to the base page in any number places (not just one place), the
> compiler would tell the child-page writer exactly what panels were
> needed, and most importantly, no additional mark-up whatsoever would
> need to be associated with any of the child pages.  (Panel classes used
> by the child page would of course have their associated mark-up.)  
>
> Eric and others explained what a bad idea it is for constructors to call
> overridable methods -- they execute before the child-page's properties
> have been set.  I usually got away with this, but I admit I was burnt a
> few times.  Recently, I wondered whether there might be a simple fix for
> the constructor-calls-overridable-method problem, such as:
>
> (a) Move the base page's component tree construction out of the
> constructor, and put it into the method:
>
> private void assembleComponents() {
> ...
> }
>
> (b) Add the property:
>
> private boolean componentsAssembled = false;
>
> (c) Override as follows to construct the component tree after the class
> constructors finish:
>
> @Override
> void onBeforeRender() {
> if ( !componentsAssembled ) {
> assembleComponents();
> componentsAssembled = true;
> }
> super.onBeforeRender(); // Or whatever else is needed
> }
>
> Then component construction would wait until the properties in both the
> parent and the subclass had been set.  I'd no longer have the problem
> associated with calling abstract methods from the constructor.
>
> Do you see any disadvantages to this approach? Is there a more
> appropriate hook upon which to hang my base page's component-tree
> assembly?
>
> If it _is_ a good approach, is there any reason the Wicket designers
> chose not to create an overrideable method in the Component class that
> is called just once after constructors terminate, and tell developers
> that this is where the component tree should be created?
>
> /Frank
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Pedro H. O. dos Santos]

Nice approach, the only missing is that you hasn't how to prevent your
component users from call addLeftNavChild after render phase at development
time. But it is no big deal, since they will get an exception at runtime...

On Thu, Oct 29, 2009 at 5:47 PM, John Krasnay <john@...> wrote:

> Rather than having the base class "pull" in components from the subclass,
> recently I've been tackling this kind of problem by creating RepeatingViews
> in
> the base class and letting subclasses "push" components in by adding to the
> repeating view:
>
>    <div class="leftNav">
>      <div wicket:id="leftNavChild" class="leftNavChild"></div>
>    </div>
>
>    public class BasePage extends WebPage {
>        private RepeatingView leftNavChildren;
>        public BasePage() {
>            add(leftNavChildren = new RepeatingView("leftNavChild"));
>        }
>        protected void addLeftNavChild(Component child) {
>            leftNavChildren.add(child);
>        }
>        protected String newLeftNavChildId() {
>            return leftNavChildren.newChildId();
>        }
>    }
>
>    public class SubPage extends BasePage {
>        public SubPage() {
>            addLeftNavChild(new MyNavPanel(newLeftNavChildId()));
>        }
>    }
>
> jk
>
> On Thu, Oct 29, 2009 at 01:50:06PM -0500, Frank Silbermann wrote:
> >
> > I was discussing glue for composing reusable panels into web pages on
> > the blog of Erik van Oosten
> > (http://blog.jteam.nl/2009/09/16/wicket-dos-and-donts/).
> >
> > I told him that my approach had been to create an abstract base page
> > that constructs the common elements while leaving place-holders for
> > page-specific panels by defining methods such as:
> >
> >       abstract Panel createUpperLeftPanel (String wicketID);
> >       abstract Panel createLowerRightPanel(String wicketID);
> >
> > and having the base page's constructor say things like:
> >
> >       Panel p1 = createUpperLeftPanel("a_wicket_id");
> >       add(p1);
> >       ...
> >       Add( createUpperRightPanel("another_wicket_id") );
> >
> > The child page's contribution would be the implementation of the
> > abstract methods.
> >
> > I explained that I preferred this to mark-up inheritance because I could
> > add to the base page in any number places (not just one place), the
> > compiler would tell the child-page writer exactly what panels were
> > needed, and most importantly, no additional mark-up whatsoever would
> > need to be associated with any of the child pages.  (Panel classes used
> > by the child page would of course have their associated mark-up.)
> >
> > Eric and others explained what a bad idea it is for constructors to call
> > overridable methods -- they execute before the child-page's properties
> > have been set.  I usually got away with this, but I admit I was burnt a
> > few times.  Recently, I wondered whether there might be a simple fix for
> > the constructor-calls-overridable-method problem, such as:
> >
> > (a) Move the base page's component tree construction out of the
> > constructor, and put it into the method:
> >
> >       private void assembleComponents() {
> >               ...
> >       }
> >
> > (b) Add the property:
> >
> >       private boolean componentsAssembled = false;
> >
> > (c) Override as follows to construct the component tree after the class
> > constructors finish:
> >
> >       @Override
> >       void onBeforeRender() {
> >               if ( !componentsAssembled ) {
> >                       assembleComponents();
> >                       componentsAssembled = true;
> >               }
> >               super.onBeforeRender(); // Or whatever else is needed
> >       }
> >
> > Then component construction would wait until the properties in both the
> > parent and the subclass had been set.  I'd no longer have the problem
> > associated with calling abstract methods from the constructor.
> >
> > Do you see any disadvantages to this approach? Is there a more
> > appropriate hook upon which to hang my base page's component-tree
> > assembly?
> >
> > If it _is_ a good approach, is there any reason the Wicket designers
> > chose not to create an overrideable method in the Component class that
> > is called just once after constructors terminate, and tell developers
> > that this is where the component tree should be created?
> >
> > /Frank
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@...
> > For additional commands, e-mail: users-help@...
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>
>

--
Pedro Henrique Oliveira dos Santos

[John Krasnay]

On Thu, Oct 29, 2009 at 05:58:02PM -0200, Pedro Santos wrote:
> Nice approach, the only missing is that you hasn't how to prevent your
> component users from call addLeftNavChild after render phase at development
> time. But it is no big deal, since they will get an exception at runtime...
>

By "component users" do you mean subclasses? They can call it from the constructor.

jk

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Pedro H. O. dos Santos]

Mean other programmes

Em 29/10/2009, às 17:00, John Krasnay <john@...> escreveu:

> On Thu, Oct 29, 2009 at 05:58:02PM -0200, Pedro Santos wrote:
>> Nice approach, the only missing is that you hasn't how to prevent  
>> your
>> component users from call addLeftNavChild after render phase at  
>> development
>> time. But it is no big deal, since they will get an exception at  
>> runtime...
>>
>
> By "component users" do you mean subclasses? They can call it from  
> the constructor.
>
> jk
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Frank Silbermann]

Having sub-pages push components to the base page (where they will live
in a ListView) looks like an effective solution.

One advantage is that the writer of SubPage can add zero, one, or many
components to (in his example) leftNavChildren.  To do that with my
base-page-pull approach, the base page's abstract method would have to
return a type of, say, List<Component>.  Then the subpage's
implementation would have to return a list of the desired length (zero,
one, or many).

A minor disadvantage of John's push-approach is that the writer of the
child page would have to rely on base page documentation or code to know
that the base page can be extended in this way.  With my approach the
compiler figuratively rubs his nose in it.

Another difference is that, with John's push approach, the base page
writer must do four things for each point of extension:

(1) declare the RepeatingView variable
(2) add the repeating view in the base page constructor
(3) provide a method called by subpages to add a component
(4) provide a method called by subpages to get the component's wicket-id

In my base-page pull method, once you've invested in the small (but
nontrivial) complexity of moving component-tree creation out of the
constructor into the "protected void assembleComponents()" method, only
two steps are required for each point of extension:

(1) define the abstract method creating the component (or
List<Component>)
(2) call it in the base page's "void assembleComponents()" method.

And perhaps the movement of component-tree construction from constructor
to "assembleComponents()" method could be done once and for all in a
base page of all base pages!

Since I'd want to follow this approach in panel construction as well as
page construction, I would have to move component-tree assembly to an
"assembleComponents()" method in my very own "BasePanel extends Panel"
class as well.

fs

-----Original Message-----
From: John Krasnay [mailto:john@...]
Sent: Thursday, October 29, 2009 2:47 PM
To: users@...
Subject: Re: Glue for composing panels

Rather than having the base class "pull" in components from the
subclass,
recently I've been tackling this kind of problem by creating
RepeatingViews in
the base class and letting subclasses "push" components in by adding to
the
repeating view:

    <div class="leftNav">
      <div wicket:id="leftNavChild" class="leftNavChild"></div>
    </div>

    public class BasePage extends WebPage {
        private RepeatingView leftNavChildren;
        public BasePage() {
            add(leftNavChildren = new RepeatingView("leftNavChild"));
        }
        protected void addLeftNavChild(Component child) {
            leftNavChildren.add(child);
        }
        protected String newLeftNavChildId() {
            return leftNavChildren.newChildId();
        }
    }

    public class SubPage extends BasePage {
        public SubPage() {
            addLeftNavChild(new MyNavPanel(newLeftNavChildId()));
        }
    }

jk

On Thu, Oct 29, 2009 at 01:50:06PM -0500, Frank Silbermann wrote:

>
> I was discussing glue for composing reusable panels into web pages on
> the blog of Erik van Oosten
> (http://blog.jteam.nl/2009/09/16/wicket-dos-and-donts/).
>
> I told him that my approach had been to create an abstract base page
> that constructs the common elements while leaving place-holders for
> page-specific panels by defining methods such as:
>
> abstract Panel createUpperLeftPanel (String wicketID);
> abstract Panel createLowerRightPanel(String wicketID);
>
> and having the base page's constructor say things like:
>
> Panel p1 = createUpperLeftPanel("a_wicket_id");
> add(p1);
> ...
> Add( createUpperRightPanel("another_wicket_id") );
>
> The child page's contribution would be the implementation of the
> abstract methods.
>  
> I explained that I preferred this to mark-up inheritance because I

could
> add to the base page in any number places (not just one place), the
> compiler would tell the child-page writer exactly what panels were
> needed, and most importantly, no additional mark-up whatsoever would
> need to be associated with any of the child pages.  (Panel classes
used
> by the child page would of course have their associated mark-up.)  
>
> Eric and others explained what a bad idea it is for constructors to
call
> overridable methods -- they execute before the child-page's properties
> have been set.  I usually got away with this, but I admit I was burnt
a
> few times.  Recently, I wondered whether there might be a simple fix
for

> the constructor-calls-overridable-method problem, such as:
>
> (a) Move the base page's component tree construction out of the
> constructor, and put it into the method:
>
> private void assembleComponents() {
> ...
> }
>
> (b) Add the property:
>
> private boolean componentsAssembled = false;
>
> (c) Override as follows to construct the component tree after the

class

> constructors finish:
>
> @Override
> void onBeforeRender() {
> if ( !componentsAssembled ) {
> assembleComponents();
> componentsAssembled = true;
> }
> super.onBeforeRender(); // Or whatever else is needed
> }
>
> Then component construction would wait until the properties in both

the

> parent and the subclass had been set.  I'd no longer have the problem
> associated with calling abstract methods from the constructor.
>
> Do you see any disadvantages to this approach? Is there a more
> appropriate hook upon which to hang my base page's component-tree
> assembly?
>
> If it _is_ a good approach, is there any reason the Wicket designers
> chose not to create an overrideable method in the Component class that
> is called just once after constructors terminate, and tell developers
> that this is where the component tree should be created?
>
> /Frank
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Martijn Dashorst]

I'm still eager to make WicketTester a first class citizen.

Martijn

On Thu, Oct 29, 2009 at 7:01 PM, dtoffe <dtoffe@...> wrote:

>
>    Thanks for your answer,
>
> Daniel
>
>
> igor.vaynberg wrote:
>>
>> the focus of this release is to rewrite url and page handling. the
>> focus is on flexibility and pluggability as well as simplification of
>> use to the end user.
>>
>> the other major feature is the markupfragment implementation, which
>> will allow users access to the markup the component is attached to,
>> possibly, at a time earlier then render time.
>>
>> other then that there will probably be smaller features that will not
>> go into 1.4.x because they require an api break.
>>
>> -igor
>>
>> On Thu, Oct 29, 2009 at 10:38 AM, dtoffe <dtoffe@...> wrote:
>>>
>>>    Besides, it would be very interesting to know what changes and new
>>> features are planned.
>>>
>>> Cheers,
>>>
>>> Daniel
>>>
>>
>>
>
> --
> View this message in context: http://www.nabble.com/Wicket-Release-Plans-for-1.5-tp26115807p26117927.html
> Sent from the Wicket - User mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>
>

--
Become a Wicket expert, learn from the best: http://wicketinaction.com
Apache Wicket 1.4 increases type safety for web applications
Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.4.0

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Haulyn R. Jason]

I am care about Can I upgrade all my applications from 1.4.3 to 1.5 as
easy as possible.

On Fri, Oct 30, 2009 at 4:27 PM, Martijn Dashorst
<martijn.dashorst@...> wrote:

> I'm still eager to make WicketTester a first class citizen.
>
> Martijn
>
> On Thu, Oct 29, 2009 at 7:01 PM, dtoffe <dtoffe@...> wrote:
>>
>>    Thanks for your answer,
>>
>> Daniel
>>
>>
>> igor.vaynberg wrote:
>>>
>>> the focus of this release is to rewrite url and page handling. the
>>> focus is on flexibility and pluggability as well as simplification of
>>> use to the end user.
>>>
>>> the other major feature is the markupfragment implementation, which
>>> will allow users access to the markup the component is attached to,
>>> possibly, at a time earlier then render time.
>>>
>>> other then that there will probably be smaller features that will not
>>> go into 1.4.x because they require an api break.
>>>
>>> -igor
>>>
>>> On Thu, Oct 29, 2009 at 10:38 AM, dtoffe <dtoffe@...> wrote:
>>>>
>>>>    Besides, it would be very interesting to know what changes and new
>>>> features are planned.
>>>>
>>>> Cheers,
>>>>
>>>> Daniel
>>>>
>>>
>>>
>>
>> --
>> View this message in context: http://www.nabble.com/Wicket-Release-Plans-for-1.5-tp26115807p26117927.html
>> Sent from the Wicket - User mailing list archive at Nabble.com.
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@...
>> For additional commands, e-mail: users-help@...
>>
>>
>
>
>
> --
> Become a Wicket expert, learn from the best: http://wicketinaction.com
> Apache Wicket 1.4 increases type safety for web applications
> Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.4.0
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>
>

--
Many thanks!

Haulyn Microproduction

You can access me with the following ways:
Location: Shandong Jinan Shumagang 6H-8, 250000
Mobile: [phone]
email: saharabear@..., hmp.haulyn@...
website: http://haulynjason.net
gtalk: saharabear@...
skype: saharabear
QQ: 378606292
persional Twitter: http://twitter.com/saharabear
persional Linkedin: http://www.linkedin.com/in/haulyn
Haulyn Microproduction Twitter: http://twitter.com/haulynmp


Haulyn Jason

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Dave B-8]

> I'm still eager to make WicketTester a first class citizen.

I'm keen on this too -- is there a 'voting' mechanism in the bug
tracker for this sort of thing?

Cheers,
Dave



On Fri, Oct 30, 2009 at 7:27 PM, Martijn Dashorst
<martijn.dashorst@...> wrote:

> I'm still eager to make WicketTester a first class citizen.
>
> Martijn
>
> On Thu, Oct 29, 2009 at 7:01 PM, dtoffe <dtoffe@...> wrote:
>>
>>    Thanks for your answer,
>>
>> Daniel
>>
>>
>> igor.vaynberg wrote:
>>>
>>> the focus of this release is to rewrite url and page handling. the
>>> focus is on flexibility and pluggability as well as simplification of
>>> use to the end user.
>>>
>>> the other major feature is the markupfragment implementation, which
>>> will allow users access to the markup the component is attached to,
>>> possibly, at a time earlier then render time.
>>>
>>> other then that there will probably be smaller features that will not
>>> go into 1.4.x because they require an api break.
>>>
>>> -igor
>>>
>>> On Thu, Oct 29, 2009 at 10:38 AM, dtoffe <dtoffe@...> wrote:
>>>>
>>>>    Besides, it would be very interesting to know what changes and new
>>>> features are planned.
>>>>
>>>> Cheers,
>>>>
>>>> Daniel
>>>>
>>>
>>>
>>
>> --
>> View this message in context: http://www.nabble.com/Wicket-Release-Plans-for-1.5-tp26115807p26117927.html
>> Sent from the Wicket - User mailing list archive at Nabble.com.
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@...
>> For additional commands, e-mail: users-help@...
>>
>>
>
>
>
> --
> Become a Wicket expert, learn from the best: http://wicketinaction.com
> Apache Wicket 1.4 increases type safety for web applications
> Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.4.0
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Richard Allen-4]

Is the Wicket Ajax Next Generation work going into 1.5?

Also, is there plans for an event bus, sort of like what you see in Jonathan
Locke's 26 wicket tricks source code? I've seen some really nice use of
event bus in GWT that I think Wicket could benefit from.

-Richard


On Fri, Oct 30, 2009 at 4:43 AM, Dave B <dave@...> wrote:

> > I'm still eager to make WicketTester a first class citizen.
>
> I'm keen on this too -- is there a 'voting' mechanism in the bug
> tracker for this sort of thing?
>
> Cheers,
> Dave
>
>
>
> On Fri, Oct 30, 2009 at 7:27 PM, Martijn Dashorst
> <martijn.dashorst@...> wrote:
> > I'm still eager to make WicketTester a first class citizen.
> >
> > Martijn
> >
> > On Thu, Oct 29, 2009 at 7:01 PM, dtoffe <dtoffe@...> wrote:
> >>
> >>    Thanks for your answer,
> >>
> >> Daniel
> >>
> >>
> >> igor.vaynberg wrote:
> >>>
> >>> the focus of this release is to rewrite url and page handling. the
> >>> focus is on flexibility and pluggability as well as simplification of
> >>> use to the end user.
> >>>
> >>> the other major feature is the markupfragment implementation, which
> >>> will allow users access to the markup the component is attached to,
> >>> possibly, at a time earlier then render time.
> >>>
> >>> other then that there will probably be smaller features that will not
> >>> go into 1.4.x because they require an api break.
> >>>
> >>> -igor
> >>>
> >>> On Thu, Oct 29, 2009 at 10:38 AM, dtoffe <dtoffe@...> wrote:
> >>>>
> >>>>    Besides, it would be very interesting to know what changes and new
> >>>> features are planned.
> >>>>
> >>>> Cheers,
> >>>>
> >>>> Daniel
> >>>>
> >>>
> >>>
> >>
> >> --
> >> View this message in context:
> http://www.nabble.com/Wicket-Release-Plans-for-1.5-tp26115807p26117927.html
> >> Sent from the Wicket - User mailing list archive at Nabble.com.
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@...
> >> For additional commands, e-mail: users-help@...
> >>
> >>
> >
> >
> >
> > --
> > Become a Wicket expert, learn from the best: http://wicketinaction.com
> > Apache Wicket 1.4 increases type safety for web applications
> > Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.4.0
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@...
> > For additional commands, e-mail: users-help@...
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>
>

[martin-g]

Hi Martijn,

What ideas do you have for this area ?
I'll be glad to help if I can.

El vie, 30-10-2009 a las 09:27 +0100, Martijn Dashorst escribió:

> I'm still eager to make WicketTester a first class citizen.
>
> Martijn
>
> On Thu, Oct 29, 2009 at 7:01 PM, dtoffe <dtoffe@...> wrote:
> >
> >    Thanks for your answer,
> >
> > Daniel
> >
> >
> > igor.vaynberg wrote:
> >>
> >> the focus of this release is to rewrite url and page handling. the
> >> focus is on flexibility and pluggability as well as simplification of
> >> use to the end user.
> >>
> >> the other major feature is the markupfragment implementation, which
> >> will allow users access to the markup the component is attached to,
> >> possibly, at a time earlier then render time.
> >>
> >> other then that there will probably be smaller features that will not
> >> go into 1.4.x because they require an api break.
> >>
> >> -igor
> >>
> >> On Thu, Oct 29, 2009 at 10:38 AM, dtoffe <dtoffe@...> wrote:
> >>>
> >>>    Besides, it would be very interesting to know what changes and new
> >>> features are planned.
> >>>
> >>> Cheers,
> >>>
> >>> Daniel
> >>>
> >>
> >>
> >
> > --
> > View this message in context: http://www.nabble.com/Wicket-Release-Plans-for-1.5-tp26115807p26117927.html
> > Sent from the Wicket - User mailing list archive at Nabble.com.
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@...
> > For additional commands, e-mail: users-help@...
> >
> >
>
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Martijn Dashorst]

Mostly component selectors a la JDave/wicket, to ensure your tests
don't fail when you modify your component hierarchy.

Martijn

On Fri, Oct 30, 2009 at 1:29 PM, Martin Grigorov <mcgregory@...> wrote:

> Hi Martijn,
>
> What ideas do you have for this area ?
> I'll be glad to help if I can.
>
> El vie, 30-10-2009 a las 09:27 +0100, Martijn Dashorst escribió:
>> I'm still eager to make WicketTester a first class citizen.
>>
>> Martijn
>>
>> On Thu, Oct 29, 2009 at 7:01 PM, dtoffe <dtoffe@...> wrote:
>> >
>> >    Thanks for your answer,
>> >
>> > Daniel
>> >
>> >
>> > igor.vaynberg wrote:
>> >>
>> >> the focus of this release is to rewrite url and page handling. the
>> >> focus is on flexibility and pluggability as well as simplification of
>> >> use to the end user.
>> >>
>> >> the other major feature is the markupfragment implementation, which
>> >> will allow users access to the markup the component is attached to,
>> >> possibly, at a time earlier then render time.
>> >>
>> >> other then that there will probably be smaller features that will not
>> >> go into 1.4.x because they require an api break.
>> >>
>> >> -igor
>> >>
>> >> On Thu, Oct 29, 2009 at 10:38 AM, dtoffe <dtoffe@...> wrote:
>> >>>
>> >>>    Besides, it would be very interesting to know what changes and new
>> >>> features are planned.
>> >>>
>> >>> Cheers,
>> >>>
>> >>> Daniel
>> >>>
>> >>
>> >>
>> >
>> > --
>> > View this message in context: http://www.nabble.com/Wicket-Release-Plans-for-1.5-tp26115807p26117927.html
>> > Sent from the Wicket - User mailing list archive at Nabble.com.
>> >
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: users-unsubscribe@...
>> > For additional commands, e-mail: users-help@...
>> >
>> >
>>
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>
>

--
Become a Wicket expert, learn from the best: http://wicketinaction.com
Apache Wicket 1.4 increases type safety for web applications
Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.4.0

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[igor.vaynberg]

possibly. i think i would like this release to be as small as
possible, centered around the new url stuff. once that is in release
1.5 and put the new ajax support from ng into 1.6.

trying to release more and more often instead of taking over a year
and a half like we did with 1.4.0

-igor

On Fri, Oct 30, 2009 at 5:10 AM, Richard Allen
<richard.l.allen@...> wrote:

> Is the Wicket Ajax Next Generation work going into 1.5?
>
> Also, is there plans for an event bus, sort of like what you see in Jonathan
> Locke's 26 wicket tricks source code? I've seen some really nice use of
> event bus in GWT that I think Wicket could benefit from.
>
> -Richard
>
>
> On Fri, Oct 30, 2009 at 4:43 AM, Dave B <dave@...> wrote:
>
>> > I'm still eager to make WicketTester a first class citizen.
>>
>> I'm keen on this too -- is there a 'voting' mechanism in the bug
>> tracker for this sort of thing?
>>
>> Cheers,
>> Dave
>>
>>
>>
>> On Fri, Oct 30, 2009 at 7:27 PM, Martijn Dashorst
>> <martijn.dashorst@...> wrote:
>> > I'm still eager to make WicketTester a first class citizen.
>> >
>> > Martijn
>> >
>> > On Thu, Oct 29, 2009 at 7:01 PM, dtoffe <dtoffe@...> wrote:
>> >>
>> >>    Thanks for your answer,
>> >>
>> >> Daniel
>> >>
>> >>
>> >> igor.vaynberg wrote:
>> >>>
>> >>> the focus of this release is to rewrite url and page handling. the
>> >>> focus is on flexibility and pluggability as well as simplification of
>> >>> use to the end user.
>> >>>
>> >>> the other major feature is the markupfragment implementation, which
>> >>> will allow users access to the markup the component is attached to,
>> >>> possibly, at a time earlier then render time.
>> >>>
>> >>> other then that there will probably be smaller features that will not
>> >>> go into 1.4.x because they require an api break.
>> >>>
>> >>> -igor
>> >>>
>> >>> On Thu, Oct 29, 2009 at 10:38 AM, dtoffe <dtoffe@...> wrote:
>> >>>>
>> >>>>    Besides, it would be very interesting to know what changes and new
>> >>>> features are planned.
>> >>>>
>> >>>> Cheers,
>> >>>>
>> >>>> Daniel
>> >>>>
>> >>>
>> >>>
>> >>
>> >> --
>> >> View this message in context:
>> http://www.nabble.com/Wicket-Release-Plans-for-1.5-tp26115807p26117927.html
>> >> Sent from the Wicket - User mailing list archive at Nabble.com.
>> >>
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: users-unsubscribe@...
>> >> For additional commands, e-mail: users-help@...
>> >>
>> >>
>> >
>> >
>> >
>> > --
>> > Become a Wicket expert, learn from the best: http://wicketinaction.com
>> > Apache Wicket 1.4 increases type safety for web applications
>> > Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.4.0
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: users-unsubscribe@...
>> > For additional commands, e-mail: users-help@...
>> >
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@...
>> For additional commands, e-mail: users-help@...
>>
>>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Vladimir K]

what about promiced auto-detaching models? may we expect it in 1.5?

igor.vaynberg wrote:

possibly. i think i would like this release to be as small as
possible, centered around the new url stuff. once that is in release
1.5 and put the new ajax support from ng into 1.6.

trying to release more and more often instead of taking over a year
and a half like we did with 1.4.0

-igor

On Fri, Oct 30, 2009 at 5:10 AM, Richard Allen
<[e-mail]> wrote:
> Is the Wicket Ajax Next Generation work going into 1.5?
>
> Also, is there plans for an event bus, sort of like what you see in Jonathan
> Locke's 26 wicket tricks source code? I've seen some really nice use of
> event bus in GWT that I think Wicket could benefit from.
>
> -Richard
>
>
> On Fri, Oct 30, 2009 at 4:43 AM, Dave B <[e-mail]> wrote:
>
>> > I'm still eager to make WicketTester a first class citizen.
>>
>> I'm keen on this too -- is there a 'voting' mechanism in the bug
>> tracker for this sort of thing?
>>
>> Cheers,
>> Dave
>>
>>
>>
>> On Fri, Oct 30, 2009 at 7:27 PM, Martijn Dashorst
>> <[e-mail]> wrote:
>> > I'm still eager to make WicketTester a first class citizen.
>> >
>> > Martijn
>> >
>> > On Thu, Oct 29, 2009 at 7:01 PM, dtoffe <[e-mail]> wrote:
>> >>
>> >>    Thanks for your answer,
>> >>
>> >> Daniel
>> >>
>> >>
>> >> igor.vaynberg wrote:
>> >>>
>> >>> the focus of this release is to rewrite url and page handling. the
>> >>> focus is on flexibility and pluggability as well as simplification of
>> >>> use to the end user.
>> >>>
>> >>> the other major feature is the markupfragment implementation, which
>> >>> will allow users access to the markup the component is attached to,
>> >>> possibly, at a time earlier then render time.
>> >>>
>> >>> other then that there will probably be smaller features that will not
>> >>> go into 1.4.x because they require an api break.
>> >>>
>> >>> -igor
>> >>>
>> >>> On Thu, Oct 29, 2009 at 10:38 AM, dtoffe <[e-mail]> wrote:
>> >>>>
>> >>>>    Besides, it would be very interesting to know what changes and new
>> >>>> features are planned.
>> >>>>
>> >>>> Cheers,
>> >>>>
>> >>>> Daniel
>> >>>>
>> >>>
>> >>>
>> >>
>> >> --
>> >> View this message in context:
>> http://www.nabble.com/Wicket-Release-Plans-for-1.5-tp26115807p26117927.html
>> >> Sent from the Wicket - User mailing list archive at Nabble.com.
>> >>
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: [e-mail]
>> >> For additional commands, e-mail: [e-mail]
>> >>
>> >>
>> >
>> >
>> >
>> > --
>> > Become a Wicket expert, learn from the best: http://wicketinaction.com
>> > Apache Wicket 1.4 increases type safety for web applications
>> > Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.4.0
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: [e-mail]
>> > For additional commands, e-mail: [e-mail]
>> >
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [e-mail]
>> For additional commands, e-mail: [e-mail]
>>
>>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [e-mail]
For additional commands, e-mail: [e-mail]