PropertyModel.of(x,y) is what we use in Model

-igor

On Thu, Dec 3, 2009 at 3:11 AM, Johan Compagner <jcompagner@gmail.com> wrote:
> the bad news is that it seems it is delayed again until the end of 2010??
>
>
> back on the static methods, PropertyModel.getInstance(x,y) is a bit to long
> i guess and PropertyModel.get(x.y)  is also not not sounding quite right.
>
>
>
> On Thu, Dec 3, 2009 at 11:42, Vladimir K <kovalyuk@gmail.com> wrote:
>
>>
>> Martijn,
>>
>> I hope a new feature called "type inference" coming in JDK7 could help java
>> devs to omit repetitive typing of generic parameters.
>>
>> And another good news - JDK 7 will do provide closures.
>>
>>
>> Martijn Dashorst wrote:
>> >
>> > I hate repeating myself and being the compiler's teacher. IMHO the
>> > generics that are implemented in Java resulted in terrible code where
>> > you have to repeat yourself over and over and over. Are you sure your
>> > text field holds a String and your model returns a String?
>> >
>> > TextField<String> field = new TextField<String>("someId", new
>> > PropertyModel<String>(foo, "property"));
>> >
>> > This counts for 3 times the type String. In a recent discussion with
>> > Igor on ##wicket, we saw a way to remove at least 1 String. By
>> > providing model factory methods for concrete models: Model,
>> > CompoundPropertyModel and PropertyModel. For abstract models it
>> > doesn't make sense...
>> >
>> > Igor suggested the following syntax:
>> >
>> > TextField<String> field = new TextField<String>("someId",
>> > PropertyModel.of(foo, "property"));
>> >
>> > i.e. ModelType.of(....)
>> >
>> > I am +1 for adding these methods.
>> >
>> > We can do the same for components, although the benefit is typically
>> > less, and it might even send our users down the wrong path thinking
>> > they can't use the 'new' keyword.
>> >
>> > TextField<String> field = TextField.of("someId", PropertyModel.of(foo,
>> > "property"));
>> >
>> > WDYT?
>> >
>> > Martijn
>> > --
>> > 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
>> >
>> >
>>
>> --
>> View this message in context:
>> http://old.nabble.com/Cutting-down-on-the-repetitive-type-identifiers-for-generics-tp26361334p26623904.html
>> Sent from the Wicket - Dev mailing list archive at Nabble.com.
>>
>>
>

the bad news is that it seems it is delayed again until the end of 2010??


back on the static methods, PropertyModel.getInstance(x,y) is a bit to long
i guess and PropertyModel.get(x.y)  is also not not sounding quite right.



On Thu, Dec 3, 2009 at 11:42, Vladimir K <kovalyuk@gmail.com> wrote:

>
> Martijn,
>
> I hope a new feature called "type inference" coming in JDK7 could help java
> devs to omit repetitive typing of generic parameters.
>
> And another good news - JDK 7 will do provide closures.
>
>
> Martijn Dashorst wrote:
> >
> > I hate repeating myself and being the compiler's teacher. IMHO the
> > generics that are implemented in Java resulted in terrible code where
> > you have to repeat yourself over and over and over. Are you sure your
> > text field holds a String and your model returns a String?
> >
> > TextField<String> field = new TextField<String>("someId", new
> > PropertyModel<String>(foo, "property"));
> >
> > This counts for 3 times the type String. In a recent discussion with
> > Igor on ##wicket, we saw a way to remove at least 1 String. By
> > providing model factory methods for concrete models: Model,
> > CompoundPropertyModel and PropertyModel. For abstract models it
> > doesn't make sense...
> >
> > Igor suggested the following syntax:
> >
> > TextField<String> field = new TextField<String>("someId",
> > PropertyModel.of(foo, "property"));
> >
> > i.e. ModelType.of(....)
> >
> > I am +1 for adding these methods.
> >
> > We can do the same for components, although the benefit is typically
> > less, and it might even send our users down the wrong path thinking
> > they can't use the 'new' keyword.
> >
> > TextField<String> field = TextField.of("someId", PropertyModel.of(foo,
> > "property"));
> >
> > WDYT?
> >
> > Martijn
> > --
> > 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
> >
> >
>
> --
> View this message in context:
> http://old.nabble.com/Cutting-down-on-the-repetitive-type-identifiers-for-generics-tp26361334p26623904.html
> Sent from the Wicket - Dev mailing list archive at Nabble.com.
>
>

Martijn,

I hope a new feature called "type inference" coming in JDK7 could help java
devs to omit repetitive typing of generic parameters.

And another good news - JDK 7 will do provide closures.


Martijn Dashorst wrote:
> 
> I hate repeating myself and being the compiler's teacher. IMHO the
> generics that are implemented in Java resulted in terrible code where
> you have to repeat yourself over and over and over. Are you sure your
> text field holds a String and your model returns a String?
> 
> TextField<String> field = new TextField<String>("someId", new
> PropertyModel<String>(foo, "property"));
> 
> This counts for 3 times the type String. In a recent discussion with
> Igor on ##wicket, we saw a way to remove at least 1 String. By
> providing model factory methods for concrete models: Model,
> CompoundPropertyModel and PropertyModel. For abstract models it
> doesn't make sense...
> 
> Igor suggested the following syntax:
> 
> TextField<String> field = new TextField<String>("someId",
> PropertyModel.of(foo, "property"));
> 
> i.e. ModelType.of(....)
> 
> I am +1 for adding these methods.
> 
> We can do the same for components, although the benefit is typically
> less, and it might even send our users down the wrong path thinking
> they can't use the 'new' keyword.
> 
> TextField<String> field = TextField.of("someId", PropertyModel.of(foo,
> "property"));
> 
> WDYT?
> 
> Martijn
> -- 
> 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
> 
> 

-- 
View this message in context: http://old.nabble.com/Cutting-down-on-the-repetitive-type-identifiers-for-generics-tp26361334p26623904.html
Sent from the Wicket - Dev mailing list archive at Nabble.com.

Would it break the API in 1.4.x?  The Panel class isn't usable as a
concrete class, so folks probably aren't doing new Panel() (and if
they are, they shouldn't be).  No big deal, really I guess.

On Wed, Dec 2, 2009 at 9:35 AM, Jonas <barney2k7@gmail.com> wrote:
> I raised the same question a while ago:
>
> http://old.nabble.com/Panel-instances-ts25922356.html#a25922356
>
> seems to be fixed in 1.5, but left as-is in 1.4 in order not to create
> an api break
>
> cheers,
> Jonas
>
>
> On Wed, Dec 2, 2009 at 12:24 PM, Johan Compagner <jcompagner@gmail.com> wrote:
>> I just got a question about:
>>
>> Markup of type 'html' for component
>> 'org.apache.wicket.markup.html.panel.Panel' not found
>>
>> because it used a panel (but he meant to use in this example a
>> WebMarkupContainer)
>> But i think he shouldnt be allowed to say new Panel() at all...
>> I would expect that it would be abstract just like Page or am i missing
>> something obvious here?
>>
>> johan
>>
>

I raised the same question a while ago:

http://old.nabble.com/Panel-instances-ts25922356.html#a25922356

seems to be fixed in 1.5, but left as-is in 1.4 in order not to create
an api break

cheers,
Jonas


On Wed, Dec 2, 2009 at 12:24 PM, Johan Compagner <jcompagner@gmail.com> wrote:
> I just got a question about:
>
> Markup of type 'html' for component
> 'org.apache.wicket.markup.html.panel.Panel' not found
>
> because it used a panel (but he meant to use in this example a
> WebMarkupContainer)
> But i think he shouldnt be allowed to say new Panel() at all...
> I would expect that it would be abstract just like Page or am i missing
> something obvious here?
>
> johan
>

I just got a question about:

Markup of type 'html' for component
'org.apache.wicket.markup.html.panel.Panel' not found

because it used a panel (but he meant to use in this example a
WebMarkupContainer)
But i think he shouldnt be allowed to say new Panel() at all...
I would expect that it would be abstract just like Page or am i missing
something obvious here?

johan

Thanks Michael.

     Erik.

Michael Mosmann wrote:
> Hope this code will make something clear.
>
> mm:)
-- 
Erik van Oosten
http://day-to-day-stuff.blogspot.com/

we can easily do this via reflection and an icomponentdetachlistener,
i was going to start looking into it after we sort the urls and push
1.5 out.

-igor

On Tue, Dec 1, 2009 at 2:41 AM, Martijn Dashorst
<martijn.dashorst@gmail.com> wrote:
> Not sure if it will fly, but couldn't we utilize the same tech as
> project lombok [1] uses to automatically generate detach code for
> IDetachables?
>
> Note that I have no idea if it will work, but considering they are
> able to generate try/finally blocks, we might be able to do something
> similar.
>
> Martijn
>
> [1] http://projectlombok.org
>

So generate a detach() methods that looks up all the fields and do what on
those?
I guess if that is a detachable call it through and annotate other fields
that should be set to null?

so i we have this

class @detachable MyModel
{
     private IModel innerModel;

    private @detach Object myVar;

    private Object id;
}

that is the same as

class MyModel
{
     private IModel innerModel;

    private myVar;

    private Object id;

    void detach()
   {
        innerModel.detach();
        myVar= null;

   }
}

but then somewhere you have to make sure that the id is set


On Tue, Dec 1, 2009 at 11:41, Martijn Dashorst
<martijn.dashorst@gmail.com>wrote:

> Not sure if it will fly, but couldn't we utilize the same tech as
> project lombok [1] uses to automatically generate detach code for
> IDetachables?
>
> Note that I have no idea if it will work, but considering they are
> able to generate try/finally blocks, we might be able to do something
> similar.
>
> Martijn
>
> [1] http://projectlombok.org
>

Not sure if it will fly, but couldn't we utilize the same tech as
project lombok [1] uses to automatically generate detach code for
IDetachables?

Note that I have no idea if it will work, but considering they are
able to generate try/finally blocks, we might be able to do something
similar.

Martijn

[1] http://projectlombok.org

While yeswicket.com won't become the new home for Wicket news (Apache
policy is: "If it isn't from *.apache.org, it ain't from Apache"),
there's nothing holding back anybody from contributing in one way or
another to this and other websites/blogs/etc.

Just keep in mind that as an Apache project, we have to be neutral and
not favor one company over another. So please continue to contribute
to yeswicket.com, wicketbyexample.com, wicketinaction.com,
martijndashorst.com, stuq.nl, java.dzone.com, infoq.com,
theserverside.com, ajaxian.com, developerworks.ibm.com, javaworld.com,
etc —to list a couple of known sites from the top of my head.

Also, please make sure your site(s) are compliant with Apache
trademark policy: http://apache.org/foundation/marks/trademarks.html

Martijn

On Mon, Nov 30, 2009 at 10:46 AM, Olivier Croisier
<olivier.croisier@gmail.com> wrote:
> Hi,
>
> We at Zenika <http://www.zenika.com> are running a site named YesWicket.com,
> on which we publish Wicket-related news (new releases...), tutorials, and
> technical articles. Until now, it targeted mainly a French audience, but we
> are willing to expand its reach by translating all articles into english, in
> the hope to gather a larger audience and build a stronger community around
> Wicket.
>
> If you are interested, we'd like to give the main Wicket leaders (Igor
> Vaynberg, Martijn Dashorst...) a write access on the blog, so they could
> publish announces, links, and articles in a more convenient and dynamic way
> than on the official site - which of course would still be the main
> reference.
> Although the categories & tags need to be reorganized, the infrastructure is
> here, ready to be used (code highlighting, attached files...).
>
> Please let us know what you think about it ! (blog~at~zenika.com if you
> prefer a more private way)
> (FYI, Carl Azoury already submitted this idea to Martijn by mail last
> Friday.)
>
> Olivier
>



-- 
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

Hi,

We at Zenika <http://www.zenika.com> are running a site named YesWicket.com,
on which we publish Wicket-related news (new releases...), tutorials, and
technical articles. Until now, it targeted mainly a French audience, but we
are willing to expand its reach by translating all articles into english, in
the hope to gather a larger audience and build a stronger community around
Wicket.

If you are interested, we'd like to give the main Wicket leaders (Igor
Vaynberg, Martijn Dashorst...) a write access on the blog, so they could
publish announces, links, and articles in a more convenient and dynamic way
than on the official site - which of course would still be the main
reference.
Although the categories & tags need to be reorganized, the infrastructure is
here, ready to be used (code highlighting, attached files...).

Please let us know what you think about it ! (blog~at~zenika.com if you
prefer a more private way)
(FYI, Carl Azoury already submitted this idea to Martijn by mail last
Friday.)

Olivier

Am Sonntag, den 29.11.2009, 20:15 +0100 schrieb Erik van Oosten:
> Michael,
> 
> What kind of container are you referring to? 

public class MyUserSession implements Serializable
{
  /* hold user relevant stuff */
}

public class MyWicketSession extends WebSession
{
  MyUserSession _container=new MyUserSession();

  public void invalidateUserSessionAndNotWicketSession()
  {
    _container=new MyUserSession();
  }
}

> And which session, the 
> servlet session or the Wicket session?

The Wicket session.

Hope this code will make something clear.

mm:)

if you never want sessions to invalidate then just have an ajax timer
that polls the server just before your container time out like 29
minutes if the time out is 30

On 19/11/2009, Hawk Newton <hnewton@cobaltgroup.com>i wrote:
> Hello Wicket folx.
>
> First and foremost I want to commend you on an excellent job putting
> together a truly impressive best-in-class framework.
>
> I'm in the process of evaluating Wicket for a large-scale ajax-heavy
> enterprise application.
>
> I've got a business requirement that session invalidation must not be a
> disruptive event (no "expired session" warning or anything similar).
>
> Some of the most obvious options:
>
> 1. Get rid of session requirements all together by using client-side models
> instead of server side models so we don't have the session invalidation
> issue.  This seems to be in line with "The next version of Wicket will
> support client-side models for zero-state scalability" line item on the
> features page.  After searching the list archives I've not seen much
> traction on this front.  Are there any potential designs being considered or
> other resources I could use to educate myself?
>
> 2. Extend WebRequestCycle.onRuntimeException() to redirect the browser back
> to the target page instead of the "expired session" error page.  This
> approach has the drawback that the model will be reset which will cause the
> page to revert to default values.  Ultimately, initializing the page using
> values from a cookie or some other stateful store that is not tied to the
> user's session would be ideal, if possible.
>
> 3. Use an external store instead of the J2EE session (like a RDBMS) with a
> data-retention policy so high the chance of a ajax request being issued
> against a page which has expired is practically nil.  We'd also probably
> need to implement our own encoder to ensure the session id is placed on
> every link to survive J2EE session invalidation.
>
> We are most-interested in contributing any substantial work back to the
> community so pointers to style guidelines or other contribution-centric
> resources are greatly appreciated.
>
> Thank you very much.
>
> -- Hawk Newton
> Enterprise Architect
> Cobalt Group, Inc.

Michael,

What kind of container are you referring to? And which session, the 
servlet session or the Wicket session?

Regards,
    Erik.


Michael Mosmann wrote:
> Hi,
>
>   
>> I've got a business requirement that session invalidation must not be a disruptive
event (no "expired session" warning or anything similar).
>>     
>
> Is session invalidation an requirement? Put a container into your
> session and throw it away if you want to invalidate the "user session".
>
> mm:)
>
>   


-- 
Erik van Oosten
http://www.day-to-day-stuff.blogspot.com/

http://wicketinaction.com/2009/11/removing-fragile-string-expressions-from-wicket-code/

-igor

Argh, that is horrible. :(


2009/11/17 Igor Vaynberg <igor.vaynberg@gmail.com>

> not to mention that some components have 6 constructors, and that
> means having 6 of methods :|
>
> -igor
>
> On Tue, Nov 17, 2009 at 9:33 AM, Jeremy Thomerson
> <jeremy@wickettraining.com> wrote:
> > Because we'll get questions to the list like:
> >
> > How can I create my own component since I have to instantiate them using
> > Label.of("foo", PropertyModel.of(bar, "foo"))?  How can I override that?
>  Do
> > I have to override the static method "of"?
> >
> > Sadly, I think that's what it will cause.
> >
> > --
> > Jeremy Thomerson
> > http://www.wickettraining.com
> >
> >
> >
> > On Tue, Nov 17, 2009 at 10:50 AM, nino martinez wael <
> > nino.martinez.wael@gmail.com> wrote:
> >
> >> im +1, unless Jeremy can tell why he believes it will hit a anti
> patter..
> >>
> >> 2009/11/16 Jeremy Thomerson <jeremy@wickettraining.com>
> >>
> >> > On Sun, Nov 15, 2009 at 11:39 AM, Martijn Dashorst <
> >> > martijn.dashorst@gmail.com> wrote:
> >> >
> >> > > i.e. ModelType.of(....)
> >> > >
> >> > > I am +1 for adding these methods.
> >> > >
> >> >
> >> > I'm +1 for the model-type methods, although there are so many models
> that
> >> > are not final classes that it really won't save tons of code.  Mainly
> in
> >> > the
> >> > *PropertyModel family.
> >> >
> >> >
> >> > > We can do the same for components, although the benefit is typically
> >> > > less, and it might even send our users down the wrong path thinking
> >> > > they can't use the 'new' keyword.
> >> > >
> >> > > TextField<String> field = TextField.of("someId",
> PropertyModel.of(foo,
> >> > > "property"));
> >> > >
> >> >
> >> > I'm -1 on doing it for components.  I think it will lead to an
> >> > anti-pattern.
> >> >
> >> > --
> >> > Jeremy Thomerson
> >> > http://www.wickettraining.com
> >> >
> >>
> >
>

ok :( do you have time to fix up what is there now and add a note to
our release doc?

-igor

On Mon, Nov 23, 2009 at 1:29 PM, Martijn Dashorst
<martijn.dashorst@gmail.com> wrote:
> On Mon, Nov 23, 2009 at 10:01 PM, Igor Vaynberg <igor.vaynberg@gmail.com> wrote:
>> or are we stuck having to add news in two different places?
>
> Usually I move stuff from the homepage to the news archive... to make
> the home page load faster. Typically only the last 3 news items on the
> front page are useful.
>
> There's no cms available that suits infra needs, and that is
> manageable by us. Or you'd rather work with anakia (again).
>
> Martijn
>
> --
> 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
>

Hehe, nice one. Never thought of that.

regards Nino
2009/11/20 Michael Mosmann <michael@mosmann.de>

> Hi,
>
> > I've got a business requirement that session invalidation must not be a
> disruptive event (no "expired session" warning or anything similar).
>
> Is session invalidation an requirement? Put a container into your
> session and throw it away if you want to invalidate the "user session".
>
> mm:)
>
>

On Mon, Nov 23, 2009 at 10:01 PM, Igor Vaynberg <igor.vaynberg@gmail.com> wrote:
> or are we stuck having to add news in two different places?

Usually I move stuff from the homepage to the news archive... to make
the home page load faster. Typically only the last 3 news items on the
front page are useful.

There's no cms available that suits infra needs, and that is
manageable by us. Or you'd rather work with anakia (again).

Martijn

-- 
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

martijn, considering we are already limited to static-only content by
our publishing, what are our options for using something then then
confluence to generate the site?

can we use some cms to manage the site somewhere and then push a
static export to apache?

or are we stuck having to add news in two different places?

-igor

On Mon, Nov 23, 2009 at 2:51 AM, nino martinez wael
<nino.martinez.wael@gmail.com> wrote:
> Hi Guys
>
> Im wondering why:
>
> http://wicket.apache.org/news.html
>
> Does not contain same information as this:
>
> http://wicket.apache.org/
>
> Mainly the information about releases..
>
> regards Nino
>

Hi Guys

Im wondering why:

http://wicket.apache.org/news.html

Does not contain same information as this:

http://wicket.apache.org/

Mainly the information about releases..

regards Nino

Hi,

> I've got a business requirement that session invalidation must not be a disruptive event
(no "expired session" warning or anything similar).

Is session invalidation an requirement? Put a container into your
session and throw it away if you want to invalidate the "user session".

mm:)

On Nov 19, 2009, at 2:24 PM, Igor Vaynberg wrote:

> On Thu, Nov 19, 2009 at 2:15 PM, Hawk Newton <hnewton@cobaltgroup.com> wrote:
>> 2. Extend WebRequestCycle.onRuntimeException() to redirect the browser back to the
target page instead of the "expired session" error page.  This approach has the drawback that
the model will be reset which will cause the page to revert to default values.  Ultimately,
initializing the page using values from a cookie or some other stateful store that is not
tied to the user's session would be ideal, if possible.
> 
> unless you encode the page class into every url there is no way to
> know what page was being accessed once the session is expired.

I got this working today provided each page is mounted as bookmarkable.  I might be missing
some of the long-reaching implications, but here's the code if anyone is interested in it:
	// In my WicketApplication class:
	public RequestCycle newRequestCycle(Request request, Response response) {
		return new WebRequestCycle(this, (WebRequest)request, (WebResponse)response) {
			@Override
			public Page onRuntimeException(Page page, RuntimeException e) {
				if(e instanceof PageExpiredException) {
					IRequestCycleProcessor processor = WicketApplication.this.getRequestCycleProcessor();
					RequestParameters params = request.getRequestParameters();
					
					// We're just looking for the original page, not a component on that page.
					String interfaceName = params.getInterfaceName();
					
					// Strip the interfaceName from the request so we can get the original target
					params.setInterfaceName(null);
					IRequestTarget target = processor.resolve(this, params);
					params.setInterfaceName(interfaceName);
					
					if(target != null && target instanceof BookmarkablePageRequestTarget) {
						Class<? extends Page> pageClass = ((BookmarkablePageRequestTarget)target).getPageClass();
						
						RequestCycle.get();	// I'm not 100% on why I need this.
						CharSequence path = processor.getRequestCodingStrategy().pathForTarget(
								new BookmarkablePageRequestTarget(pageClass));
						
						if(path != null) {
							// This is a bookmarkable page, so lets send the user to the bookmark
							RequestCycle.get().setRedirect(true);
							throw new RestartResponseException(pageClass);
						}
					}
				}
				return null;
			}
		};
	}


> 
>> 3. Use an external store instead of the J2EE session (like a RDBMS) with a data-retention
policy so high the chance of a ajax request being issued against a page which has expired
is practically nil.  We'd also probably need to implement our own encoder to ensure the session
id is placed on every link to survive J2EE session invalidation.
> 
> or simply set the j2ee session timeout to a high value. servlet
> containers these days can swap inactive sessions to disk to keep the
> memory overhead low. same effect and no need to deal with a database.
> 
> -igor

Thank you, with a high enough session timeout and a disk-backed session overflow we should
be good.

-- Hawk

On Thu, Nov 19, 2009 at 2:15 PM, Hawk Newton <hnewton@cobaltgroup.com> wrote:
> Hello Wicket folx.
>
> First and foremost I want to commend you on an excellent job putting together a truly
impressive best-in-class framework.
>
> I'm in the process of evaluating Wicket for a large-scale ajax-heavy enterprise application.
>
> I've got a business requirement that session invalidation must not be a disruptive event
(no "expired session" warning or anything similar).

if this is a hard requirement you may be best served by a client-side
framework like gwt or extjs.

> Some of the most obvious options:
>
> 1. Get rid of session requirements all together by using client-side models instead of
server side models so we don't have the session invalidation issue.  This seems to be in line
with "The next version of Wicket will support client-side models for zero-state scalability"
line item on the features page.  After searching the list archives I've not seen much traction
on this front.  Are there any potential designs being considered or other resources I could
use to educate myself?

no, we have evaluated this option and decided not to pursue it
further. the discussions are on the list if you want to search, but
the agreement was that ram is cheap, disks are even cheaper, and the
overhead of pushing all relevant state to the client is too high. we
have built support for stateless pages, but there is no support for
stateless ajax, and in order to keep a stateless page stateless you
are limited to a subset of components offered by wicket which are
themselves stateless.

> 2. Extend WebRequestCycle.onRuntimeException() to redirect the browser back to the target
page instead of the "expired session" error page.  This approach has the drawback that the
model will be reset which will cause the page to revert to default values.  Ultimately, initializing
the page using values from a cookie or some other stateful store that is not tied to the user's
session would be ideal, if possible.

unless you encode the page class into every url there is no way to
know what page was being accessed once the session is expired.

> 3. Use an external store instead of the J2EE session (like a RDBMS) with a data-retention
policy so high the chance of a ajax request being issued against a page which has expired
is practically nil.  We'd also probably need to implement our own encoder to ensure the session
id is placed on every link to survive J2EE session invalidation.

or simply set the j2ee session timeout to a high value. servlet
containers these days can swap inactive sessions to disk to keep the
memory overhead low. same effect and no need to deal with a database.

-igor

> We are most-interested in contributing any substantial work back to the community so
pointers to style guidelines or other contribution-centric resources are greatly appreciated.
>
> Thank you very much.
>
> -- Hawk Newton
> Enterprise Architect
> Cobalt Group, Inc.

Hello Wicket folx.

First and foremost I want to commend you on an excellent job putting together a truly impressive
best-in-class framework.

I'm in the process of evaluating Wicket for a large-scale ajax-heavy enterprise application.

I've got a business requirement that session invalidation must not be a disruptive event (no
"expired session" warning or anything similar).

Some of the most obvious options:

1. Get rid of session requirements all together by using client-side models instead of server
side models so we don't have the session invalidation issue.  This seems to be in line with
"The next version of Wicket will support client-side models for zero-state scalability" line
item on the features page.  After searching the list archives I've not seen much traction
on this front.  Are there any potential designs being considered or other resources I could
use to educate myself?

2. Extend WebRequestCycle.onRuntimeException() to redirect the browser back to the target
page instead of the "expired session" error page.  This approach has the drawback that the
model will be reset which will cause the page to revert to default values.  Ultimately, initializing
the page using values from a cookie or some other stateful store that is not tied to the user's
session would be ideal, if possible.

3. Use an external store instead of the J2EE session (like a RDBMS) with a data-retention
policy so high the chance of a ajax request being issued against a page which has expired
is practically nil.  We'd also probably need to implement our own encoder to ensure the session
id is placed on every link to survive J2EE session invalidation.

We are most-interested in contributing any substantial work back to the community so pointers
to style guidelines or other contribution-centric resources are greatly appreciated.

Thank you very much.

-- Hawk Newton
Enterprise Architect
Cobalt Group, Inc.

meanwhile i am working on bindgen.org to make it play nice with wicket.

-igor

On Wed, Nov 18, 2009 at 3:38 PM, Johan Compagner <jcompagner@gmail.com> wrote:
> http://java.dzone.com/news/closures-coming-java-7 ->
> http://docs.google.com/Doc?id=ddhp95vd_6hg3qhc
>
> then that would pretty much solve our none static typed property model in
> java 7
>

http://java.dzone.com/news/closures-coming-java-7 ->
http://docs.google.com/Doc?id=ddhp95vd_6hg3qhc

then that would pretty much solve our none static typed property model in
java 7

Hi there,

I opened a JIRA
(WICKET-2581<https://issues.apache.org/jira/browse/WICKET-2581>)
asking to translate wicket-auth-roles resources to French, and provided a
patch that does just that.
Hope that helps !

Olivier

not to mention that some components have 6 constructors, and that
means having 6 of methods :|

-igor

On Tue, Nov 17, 2009 at 9:33 AM, Jeremy Thomerson
<jeremy@wickettraining.com> wrote:
> Because we'll get questions to the list like:
>
> How can I create my own component since I have to instantiate them using
> Label.of("foo", PropertyModel.of(bar, "foo"))?  How can I override that?  Do
> I have to override the static method "of"?
>
> Sadly, I think that's what it will cause.
>
> --
> Jeremy Thomerson
> http://www.wickettraining.com
>
>
>
> On Tue, Nov 17, 2009 at 10:50 AM, nino martinez wael <
> nino.martinez.wael@gmail.com> wrote:
>
>> im +1, unless Jeremy can tell why he believes it will hit a anti patter..
>>
>> 2009/11/16 Jeremy Thomerson <jeremy@wickettraining.com>
>>
>> > On Sun, Nov 15, 2009 at 11:39 AM, Martijn Dashorst <
>> > martijn.dashorst@gmail.com> wrote:
>> >
>> > > i.e. ModelType.of(....)
>> > >
>> > > I am +1 for adding these methods.
>> > >
>> >
>> > I'm +1 for the model-type methods, although there are so many models that
>> > are not final classes that it really won't save tons of code.  Mainly in
>> > the
>> > *PropertyModel family.
>> >
>> >
>> > > We can do the same for components, although the benefit is typically
>> > > less, and it might even send our users down the wrong path thinking
>> > > they can't use the 'new' keyword.
>> > >
>> > > TextField<String> field = TextField.of("someId", PropertyModel.of(foo,
>> > > "property"));
>> > >
>> >
>> > I'm -1 on doing it for components.  I think it will lead to an
>> > anti-pattern.
>> >
>> > --
>> > Jeremy Thomerson
>> > http://www.wickettraining.com
>> >
>>
>

Because we'll get questions to the list like:

How can I create my own component since I have to instantiate them using
Label.of("foo", PropertyModel.of(bar, "foo"))?  How can I override that?  Do
I have to override the static method "of"?

Sadly, I think that's what it will cause.

--
Jeremy Thomerson
http://www.wickettraining.com



On Tue, Nov 17, 2009 at 10:50 AM, nino martinez wael <
nino.martinez.wael@gmail.com> wrote:

> im +1, unless Jeremy can tell why he believes it will hit a anti patter..
>
> 2009/11/16 Jeremy Thomerson <jeremy@wickettraining.com>
>
> > On Sun, Nov 15, 2009 at 11:39 AM, Martijn Dashorst <
> > martijn.dashorst@gmail.com> wrote:
> >
> > > i.e. ModelType.of(....)
> > >
> > > I am +1 for adding these methods.
> > >
> >
> > I'm +1 for the model-type methods, although there are so many models that
> > are not final classes that it really won't save tons of code.  Mainly in
> > the
> > *PropertyModel family.
> >
> >
> > > We can do the same for components, although the benefit is typically
> > > less, and it might even send our users down the wrong path thinking
> > > they can't use the 'new' keyword.
> > >
> > > TextField<String> field = TextField.of("someId", PropertyModel.of(foo,
> > > "property"));
> > >
> >
> > I'm -1 on doing it for components.  I think it will lead to an
> > anti-pattern.
> >
> > --
> > Jeremy Thomerson
> > http://www.wickettraining.com
> >
>

I know it is an minor thing, but the creation act that the new keyword
exposes, the 'of' method don't has. IMO the simple fact of an method name
does not contain an verb is an anti-pattern.

On Tue, Nov 17, 2009 at 2:50 PM, nino martinez wael <
nino.martinez.wael@gmail.com> wrote:

> im +1, unless Jeremy can tell why he believes it will hit a anti patter..
>
> 2009/11/16 Jeremy Thomerson <jeremy@wickettraining.com>
>
> > On Sun, Nov 15, 2009 at 11:39 AM, Martijn Dashorst <
> > martijn.dashorst@gmail.com> wrote:
> >
> > > i.e. ModelType.of(....)
> > >
> > > I am +1 for adding these methods.
> > >
> >
> > I'm +1 for the model-type methods, although there are so many models that
> > are not final classes that it really won't save tons of code.  Mainly in
> > the
> > *PropertyModel family.
> >
> >
> > > We can do the same for components, although the benefit is typically
> > > less, and it might even send our users down the wrong path thinking
> > > they can't use the 'new' keyword.
> > >
> > > TextField<String> field = TextField.of("someId", PropertyModel.of(foo,
> > > "property"));
> > >
> >
> > I'm -1 on doing it for components.  I think it will lead to an
> > anti-pattern.
> >
> > --
> > Jeremy Thomerson
> > http://www.wickettraining.com
> >
>



-- 
Pedro Henrique Oliveira dos Santos

im +1, unless Jeremy can tell why he believes it will hit a anti patter..

2009/11/16 Jeremy Thomerson <jeremy@wickettraining.com>

> On Sun, Nov 15, 2009 at 11:39 AM, Martijn Dashorst <
> martijn.dashorst@gmail.com> wrote:
>
> > i.e. ModelType.of(....)
> >
> > I am +1 for adding these methods.
> >
>
> I'm +1 for the model-type methods, although there are so many models that
> are not final classes that it really won't save tons of code.  Mainly in
> the
> *PropertyModel family.
>
>
> > We can do the same for components, although the benefit is typically
> > less, and it might even send our users down the wrong path thinking
> > they can't use the 'new' keyword.
> >
> > TextField<String> field = TextField.of("someId", PropertyModel.of(foo,
> > "property"));
> >
>
> I'm -1 on doing it for components.  I think it will lead to an
> anti-pattern.
>
> --
> Jeremy Thomerson
> http://www.wickettraining.com
>

Hi,

After 13 months I finally got around creating a proper patch for the 
wrong autocomplete dropdown positioning, 
(https://issues.apache.org/jira/browse/WICKET-1355).

I added 2 patch files to the issue, one for 1.3.x, and one for 1.4.x/trunk.

The patches are based on a version I created to patch wicket 1.3.6. The 
changes are very straight forward but I did not actually test the 
patches on 1.3.x, 1.4.x nor trunk. Please let me know if it works for you.

Regards,
    Erik.

-- 
Erik van Oosten
http://day-to-day-stuff.blogspot.com/

On Sun, Nov 15, 2009 at 11:39 AM, Martijn Dashorst <
martijn.dashorst@gmail.com> wrote:

> i.e. ModelType.of(....)
>
> I am +1 for adding these methods.
>

I'm +1 for the model-type methods, although there are so many models that
are not final classes that it really won't save tons of code.  Mainly in the
*PropertyModel family.


> We can do the same for components, although the benefit is typically
> less, and it might even send our users down the wrong path thinking
> they can't use the 'new' keyword.
>
> TextField<String> field = TextField.of("someId", PropertyModel.of(foo,
> "property"));
>

I'm -1 on doing it for components.  I think it will lead to an
anti-pattern.

--
Jeremy Thomerson
http://www.wickettraining.com

I hate repeating myself and being the compiler's teacher. IMHO the
generics that are implemented in Java resulted in terrible code where
you have to repeat yourself over and over and over. Are you sure your
text field holds a String and your model returns a String?

TextField<String> field = new TextField<String>("someId", new
PropertyModel<String>(foo, "property"));

This counts for 3 times the type String. In a recent discussion with
Igor on ##wicket, we saw a way to remove at least 1 String. By
providing model factory methods for concrete models: Model,
CompoundPropertyModel and PropertyModel. For abstract models it
doesn't make sense...

Igor suggested the following syntax:

TextField<String> field = new TextField<String>("someId",
PropertyModel.of(foo, "property"));

i.e. ModelType.of(....)

I am +1 for adding these methods.

We can do the same for components, although the benefit is typically
less, and it might even send our users down the wrong path thinking
they can't use the 'new' keyword.

TextField<String> field = TextField.of("someId", PropertyModel.of(foo,
"property"));

WDYT?

Martijn
-- 
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

done

-igor

On Thu, Nov 12, 2009 at 1:06 PM, phpmedia <phpmedia@gmail.com> wrote:
> hello list,
>
> i would like to have commit access.
>
> my sourceforge-id is "blade23" .
>
> thx,
>
> dirk
>

hello list,

i would like to have commit access.

my sourceforge-id is "blade23" .

thx,

dirk

Component is optional so it can be given optionally to the renderer.

I have attached a patch. However, it should still be coupled with
TypeChoiceModel so that they fetch the localized label using the same
method. I uploaded that too.

I also provided factory methods so that it is easier to construct these objects.

**
Martin

2009/11/12 Olivier Croisier <olivier.croisier@gmail.com>:
> The Localizer methods also require a Component as a parameter, so we're back
> to square one : we must provide a Component.
> Also, it would be helpful if you provided your alternative implementation as
> a well-formed patch instead of plain-text code in the Jira comment.
>
>
> On Wed, Nov 11, 2009 at 8:44 PM, Martin Makundi <
> martin.makundi@koodaripalvelut.com> wrote:
>
>> > I admit the EnumDropDownChoice is more of a convenient class that a
>> > real new feature.
>>
>> It's simply an overkill for the purpose. I loved the idea of a
>> TypeChoiceModel, though. Maybe it should also be tuned to be non
>> enum-specific, like the TypeChoiceRenderer.
>>
>> > A standalone EnumChoiceRenderer would need to take a Component as a
>> > constructor parameter, to call getString() on,
>>
>> This is not true. Localizer is available everywhere.
>>
>> Application.get().getResourceSettings().getLocalizer();
>>
>>
>> **
>> Martin
>> >
>> >
>> >
>> >
>> > On Wed, Nov 11, 2009 at 7:58 PM, Martin Makundi <
>> > martin.makundi@koodaripalvelut.com> wrote:
>> >
>> >> I vote for EnumChoiceRender instead of full DropDownChoice.
>> >>
>> >> However. EnumChoiceRenderer can render any TYPE so that's why I have
>> >> proposed TypeChoiceRenderer. You can directly use it with existing
>> >> wicket and no need for specific dropdown.
>> >>
>> >> **
>> >> Martin
>> >>
>> >> 2009/11/11 Olivier Croisier <olivier.croisier@gmail.com>:
>> >> > Hi,
>> >> >
>> >> > I just submitted a patch to the very old
>> >> > WICKET-1157<https://issues.apache.org/jira/browse/WICKET-1157>JIRA
>> (no
>> >> > activity for the last 2 years).
>> >> > It provides a simple and flexible way to internationalize enums :
>> >> > - An EnumMessageKeyProvided that implements a Strategy pattern to
>> >> generate
>> >> > I18N keys from enums.
>> >> > - An EnumDropDownChoice to render HTML <select> components
>> >> > - An EnumModel to internationalize any enum provided by another Model
>> (so
>> >> > there is no need of EnumLabels and such).
>> >> >
>> >> > Hope that helps,
>> >> >
>> >> > Olivier
>> >> >
>> >>
>> >
>>
>

The Localizer methods also require a Component as a parameter, so we're back
to square one : we must provide a Component.
Also, it would be helpful if you provided your alternative implementation as
a well-formed patch instead of plain-text code in the Jira comment.


On Wed, Nov 11, 2009 at 8:44 PM, Martin Makundi <
martin.makundi@koodaripalvelut.com> wrote:

> > I admit the EnumDropDownChoice is more of a convenient class that a
> > real new feature.
>
> It's simply an overkill for the purpose. I loved the idea of a
> TypeChoiceModel, though. Maybe it should also be tuned to be non
> enum-specific, like the TypeChoiceRenderer.
>
> > A standalone EnumChoiceRenderer would need to take a Component as a
> > constructor parameter, to call getString() on,
>
> This is not true. Localizer is available everywhere.
>
> Application.get().getResourceSettings().getLocalizer();
>
>
> **
> Martin
> >
> >
> >
> >
> > On Wed, Nov 11, 2009 at 7:58 PM, Martin Makundi <
> > martin.makundi@koodaripalvelut.com> wrote:
> >
> >> I vote for EnumChoiceRender instead of full DropDownChoice.
> >>
> >> However. EnumChoiceRenderer can render any TYPE so that's why I have
> >> proposed TypeChoiceRenderer. You can directly use it with existing
> >> wicket and no need for specific dropdown.
> >>
> >> **
> >> Martin
> >>
> >> 2009/11/11 Olivier Croisier <olivier.croisier@gmail.com>:
> >> > Hi,
> >> >
> >> > I just submitted a patch to the very old
> >> > WICKET-1157<https://issues.apache.org/jira/browse/WICKET-1157>JIRA
> (no
> >> > activity for the last 2 years).
> >> > It provides a simple and flexible way to internationalize enums :
> >> > - An EnumMessageKeyProvided that implements a Strategy pattern to
> >> generate
> >> > I18N keys from enums.
> >> > - An EnumDropDownChoice to render HTML <select> components
> >> > - An EnumModel to internationalize any enum provided by another Model
> (so
> >> > there is no need of EnumLabels and such).
> >> >
> >> > Hope that helps,
> >> >
> >> > Olivier
> >> >
> >>
> >
>