Nabble - Wicket - Dev

PropertyModels without strings

2009-11-25T13:56:06Z

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

-igor

Re: Cutting down on the repetitive type identifiers for generics

2009-11-24T02:00:46Z

Argh, that is horrible. :(

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

> 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@...> 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@...> wrote:
> >
> >> im +1, unless Jeremy can tell why he believes it will hit a anti
> patter..
> >>
> >> 2009/11/16 Jeremy Thomerson <jeremy@...>
> >>
> >> > On Sun, Nov 15, 2009 at 11:39 AM, Martijn Dashorst <
> >> > martijn.dashorst@...> 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
> >> >
> >>
> >
>

Re: http://wicket.apache.org

2009-11-23T13:31:03Z

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@...> wrote:

> On Mon, Nov 23, 2009 at 10:01 PM, Igor Vaynberg <igor.vaynberg@...> 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
>

Re: Session Invalidation Options

2009-11-23T13:30:01Z

Hehe, nice one. Never thought of that.

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

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

Re: http://wicket.apache.org

2009-11-23T13:29:11Z

On Mon, Nov 23, 2009 at 10:01 PM, Igor Vaynberg <igor.vaynberg@...> 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

Re: http://wicket.apache.org

2009-11-23T13:01:54Z

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

http://wicket.apache.org

2009-11-23T02:51:11Z

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

Re: Session Invalidation Options

2009-11-20T04:02:27Z

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

Re: Session Invalidation Options

2009-11-19T15:18:32Z

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

> On Thu, Nov 19, 2009 at 2:15 PM, Hawk Newton <hnewton@...> 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

Re: Session Invalidation Options

2009-11-19T14:24:35Z

On Thu, Nov 19, 2009 at 2:15 PM, Hawk Newton <hnewton@...> 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.

Session Invalidation Options

2009-11-19T14:15:01Z

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.

Re: if this is true.

2009-11-18T15:42:32Z

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

if this is true.

2009-11-18T15:38:28Z

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

Wicket-auth-roles : French translation

2009-11-18T15:07:53Z

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

Re: Cutting down on the repetitive type identifiers for generics

2009-11-17T09:36:15Z

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@...> 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@...> wrote:
>
>> im +1, unless Jeremy can tell why he believes it will hit a anti patter..
>>
>> 2009/11/16 Jeremy Thomerson <jeremy@...>
>>
>> > On Sun, Nov 15, 2009 at 11:39 AM, Martijn Dashorst <
>> > martijn.dashorst@...> 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
>> >
>>
>

Re: Cutting down on the repetitive type identifiers for generics

2009-11-17T09:33:37Z

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@...> wrote:

> im +1, unless Jeremy can tell why he believes it will hit a anti patter..
>
> 2009/11/16 Jeremy Thomerson <jeremy@...>
>
> > On Sun, Nov 15, 2009 at 11:39 AM, Martijn Dashorst <
> > martijn.dashorst@...> 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
> >
>

Re: Cutting down on the repetitive type identifiers for generics

2009-11-17T09:17:38Z

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@...> wrote:

--
Pedro Henrique Oliveira dos Santos

Re: Cutting down on the repetitive type identifiers for generics

2009-11-17T08:50:03Z

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

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

> On Sun, Nov 15, 2009 at 11:39 AM, Martijn Dashorst <
> martijn.dashorst@...> 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
>

WICKET-1355 autocomplete positioning

2009-11-17T07:06:30Z

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/

Re: Cutting down on the repetitive type identifiers for generics

2009-11-15T16:14:13Z

On Sun, Nov 15, 2009 at 11:39 AM, Martijn Dashorst <
martijn.dashorst@...> 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

Cutting down on the repetitive type identifiers for generics

2009-11-15T09:39:44Z

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

Re: Wicket Stuff commit access

2009-11-12T14:31:42Z

done

-igor

On Thu, Nov 12, 2009 at 1:06 PM, phpmedia <phpmedia@...> wrote:

> hello list,
>
> i would like to have commit access.
>
> my sourceforge-id is "blade23" .
>
> thx,
>
> dirk
>

Wicket Stuff commit access

2009-11-12T13:06:32Z

hello list,

i would like to have commit access.

my sourceforge-id is "blade23" .

thx,

dirk

Re: Patch for easy Enums I18N

2009-11-11T21:30:24Z

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@...>:

> 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@...> 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@...> 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@...>:
>> >> > 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
>> >> >
>> >>
>> >
>>
>

Re: Patch for easy Enums I18N

2009-11-11T14:20:52Z

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@...> 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@...> 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@...>:
> >> > 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
> >> >
> >>
> >
>

Re: Patch for easy Enums I18N

2009-11-11T11:44:51Z

> 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@...> 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@...>:
>> > 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
>> >
>>
>

Re: Patch for easy Enums I18N

2009-11-11T11:36:03Z

Hi,

Thanks for your answer.

I admit the EnumDropDownChoice is more of a convenient class that a real new
feature.
However, it has the benefit of providing its enclosed EnumChoiceRenderer a
base component to call getString() on. A standalone EnumChoiceRenderer would
need to take a Component as a constructor parameter, to call getString() on,
and I thought it might be a bit confusing for the developers.
Now, if everyone finds it better, I am willing to submit a new patch with
only the EnumChoiceRenderer, modified as required.

On the other hand, any remarks on the EnumMessageKeyProvider system ?

Olivier

On Wed, Nov 11, 2009 at 7:58 PM, Martin Makundi <
martin.makundi@...> 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@...>:
> > 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
> >
>

Re: Patch for easy Enums I18N

2009-11-11T10:58:26Z

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@...>:

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

Re: Patch submitted for Enum-ification of the runtime configuration types

2009-11-11T10:39:24Z

Hi Olivier,

Thanks for explaining!
My opinion is that if j.l.String is used properly then it is sufficient
for this use case. One benefit in your solution is the parsing of the
JVM/web init-param property. Now it warns when unknown value is
provided.
There are few comments about the patch though:
- it seems you don't use the Eclipse's preferences which come with
Wicket's code. I guess you use another IDE. All imports are folded
(+ import org.apache.wicket.*) and many indentations are broken
- there is a dead local variable in the code related to parsing of
JVM/init-param property

Keep the good work!

On Wed, 2009-11-11 at 17:26 +0100, Olivier Croisier wrote:

> The benefit is that the code doesn't rely on string literal
> comparison, which is inherently neither secure nor
> refactoring-friendly.
> Ex: Before my patch, there was at least one == string comparison,
> which result may vary depending on whether the strings are intern()-ed
> or not.
> Enums prevent that sort of errors, and ensure that constants are
> defined in only one place (the enum class) instead of maybe being
> scattered across many classes (you can define string literals
> anywhere).
>
> BTW, I'm not sure the configuration type modularization, as proposed
> by WICKET-1847, is a good idea.
> Let me explain my point of view :
> IMO, the runtime level belongs to wicket internals and shall not be
> used by users to tweak their applications. And for the Wicket engine,
> only two modes are relevant : debug ("development") and "not
> debug" (ie, deployment). Also, these modes are referred to in many
> places throughout the code ; allowing user-defined runtime types would
> require to give them access to lots of Wicket's internals. There are
> already too many special corner cases in the main and sub-projects
> with the existing two modes.
>
> So I think the user customisation, if really needed, would be better
> implemented by another system ("profiles" ?) that would deal only with
> the startup configuration (ie, tune the various *Settings), and would
> be applied after the existing development/deployment default
> configuration. Such profiles could be detected using the Service
> Provider API for example, and selected by an init-parameter.
>
> What do you think ?
>
> Olivier
>
>
>
>
>
>
> On Wed, Nov 11, 2009 at 4:08 PM, Martin Grigorov <mcgregory@...>
> wrote:
> On Wed, 2009-11-11 at 15:59 +0100, Olivier Croisier wrote:
> > Hi,
> >
> > WICKET-1847 is more than a year old and has had no activity
> for more than a
> > year, whereas the WICKET-1945 was more revent and seemed
> interesting to me,
> > so I corrected it.
> > But in my opinion, even if the former is the target
> architecture, nothing
> > prevents from integrating my patch now (in the 1.4.x branch
> for example) and
> > benefit from the type safety in the meantime.
>
> What is the actual benefit of this type safety?
>
> If it is prefered to be enum I would prefer to use
> org.apache.wicket.util.lang.EnumeratedType which is
> extendable.
>
> >
> > Olivier
> >
> >
> > On Wed, Nov 11, 2009 at 3:42 PM, Jonas <barney2k7@...>
> wrote:
> >
> > > I thought the plan for 1.5 was going into the opposite
> direction:
> > > https://issues.apache.org/jira/browse/WICKET-1847
> > >
> > > On Wed, Nov 11, 2009 at 3:34 PM, Olivier Croisier
> > > <olivier.croisier@...> wrote:
> > > > Hi,
> > > >
> > > > I just submitted a patch that converts the runtime
> configuration types
> > > > ("development", "deployment") into a type-safe Enum.
> > > > See https://issues.apache.org/jira/browse/WICKET-1945
> > > >
> > > > Hope that helps,
> > > > Olivier
> > > >
> > >
>
>
>
>

Patch for easy Enums I18N

2009-11-11T09:47:41Z

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

Re: Patch submitted for Enum-ification of the runtime configuration types

2009-11-11T08:26:57Z

The benefit is that the code doesn't rely on string literal comparison,
which is inherently neither secure nor refactoring-friendly.
Ex: Before my patch, there was at least one == string comparison, which
result may vary depending on whether the strings are intern()-ed or not.
Enums prevent that sort of errors, and ensure that constants are defined in
only one place (the enum class) instead of maybe being scattered across many
classes (you can define string literals anywhere).

BTW, I'm not sure the configuration type modularization, as proposed by
WICKET-1847, is a good idea.
Let me explain my point of view :
IMO, the runtime level belongs to wicket internals and shall not be used by
users to tweak their applications. And for the Wicket engine, only two modes
are relevant : debug ("development") and "not debug" (ie, deployment). Also,
these modes are referred to in many places throughout the code ; allowing
user-defined runtime types would require to give them access to lots of
Wicket's internals. There are already too many special corner cases in the
main and sub-projects with the existing two modes.

So I think the user customisation, if really needed, would be better
implemented by another system ("profiles" ?) that would deal only with the
startup configuration (ie, tune the various *Settings), and would be applied
after the existing development/deployment default configuration. Such
profiles could be detected using the Service Provider API for example, and
selected by an init-parameter.

What do you think ?

Olivier

On Wed, Nov 11, 2009 at 4:08 PM, Martin Grigorov <mcgregory@...>wrote:

> On Wed, 2009-11-11 at 15:59 +0100, Olivier Croisier wrote:
> > Hi,
> >
> > WICKET-1847 is more than a year old and has had no activity for more than
> a
> > year, whereas the WICKET-1945 was more revent and seemed interesting to
> me,
> > so I corrected it.
> > But in my opinion, even if the former is the target architecture, nothing
> > prevents from integrating my patch now (in the 1.4.x branch for example)
> and
> > benefit from the type safety in the meantime.
> What is the actual benefit of this type safety?
>
> If it is prefered to be enum I would prefer to use
> org.apache.wicket.util.lang.EnumeratedType which is extendable.
> >
> > Olivier
> >
> >
> > On Wed, Nov 11, 2009 at 3:42 PM, Jonas <barney2k7@...> wrote:
> >
> > > I thought the plan for 1.5 was going into the opposite direction:
> > > https://issues.apache.org/jira/browse/WICKET-1847
> > >
> > > On Wed, Nov 11, 2009 at 3:34 PM, Olivier Croisier
> > > <olivier.croisier@...> wrote:
> > > > Hi,
> > > >
> > > > I just submitted a patch that converts the runtime configuration
> types
> > > > ("development", "deployment") into a type-safe Enum.
> > > > See https://issues.apache.org/jira/browse/WICKET-1945
> > > >
> > > > Hope that helps,
> > > > Olivier
> > > >
> > >
>
>
>

Re: Patch submitted for Enum-ification of the runtime configuration types

2009-11-11T07:08:16Z

On Wed, 2009-11-11 at 15:59 +0100, Olivier Croisier wrote:
> Hi,
>
> WICKET-1847 is more than a year old and has had no activity for more than a
> year, whereas the WICKET-1945 was more revent and seemed interesting to me,
> so I corrected it.
> But in my opinion, even if the former is the target architecture, nothing
> prevents from integrating my patch now (in the 1.4.x branch for example) and
> benefit from the type safety in the meantime.
What is the actual benefit of this type safety?

If it is prefered to be enum I would prefer to use
org.apache.wicket.util.lang.EnumeratedType which is extendable.

>
> Olivier
>
>
> On Wed, Nov 11, 2009 at 3:42 PM, Jonas <barney2k7@...> wrote:
>
> > I thought the plan for 1.5 was going into the opposite direction:
> > https://issues.apache.org/jira/browse/WICKET-1847
> >
> > On Wed, Nov 11, 2009 at 3:34 PM, Olivier Croisier
> > <olivier.croisier@...> wrote:
> > > Hi,
> > >
> > > I just submitted a patch that converts the runtime configuration types
> > > ("development", "deployment") into a type-safe Enum.
> > > See https://issues.apache.org/jira/browse/WICKET-1945
> > >
> > > Hope that helps,
> > > Olivier
> > >
> >

Re: Patch submitted for Enum-ification of the runtime configuration types

2009-11-11T06:59:09Z

Hi,

WICKET-1847 is more than a year old and has had no activity for more than a
year, whereas the WICKET-1945 was more revent and seemed interesting to me,
so I corrected it.
But in my opinion, even if the former is the target architecture, nothing
prevents from integrating my patch now (in the 1.4.x branch for example) and
benefit from the type safety in the meantime.

Olivier

On Wed, Nov 11, 2009 at 3:42 PM, Jonas <barney2k7@...> wrote:

> I thought the plan for 1.5 was going into the opposite direction:
> https://issues.apache.org/jira/browse/WICKET-1847
>
> On Wed, Nov 11, 2009 at 3:34 PM, Olivier Croisier
> <olivier.croisier@...> wrote:
> > Hi,
> >
> > I just submitted a patch that converts the runtime configuration types
> > ("development", "deployment") into a type-safe Enum.
> > See https://issues.apache.org/jira/browse/WICKET-1945
> >
> > Hope that helps,
> > Olivier
> >
>

Re: Patch submitted for Enum-ification of the runtime configuration types

2009-11-11T06:42:55Z

I thought the plan for 1.5 was going into the opposite direction:
https://issues.apache.org/jira/browse/WICKET-1847

On Wed, Nov 11, 2009 at 3:34 PM, Olivier Croisier
<olivier.croisier@...> wrote:
> Hi,
>
> I just submitted a patch that converts the runtime configuration types
> ("development", "deployment") into a type-safe Enum.
> See https://issues.apache.org/jira/browse/WICKET-1945
>
> Hope that helps,
> Olivier
>

Patch submitted for Enum-ification of the runtime configuration types

2009-11-11T06:34:47Z

Hi,

I just submitted a patch that converts the runtime configuration types
("development", "deployment") into a type-safe Enum.
See https://issues.apache.org/jira/browse/WICKET-1945

Hope that helps,
Olivier

Nabble - Wicket - Dev

PropertyModels *without* strings

Re: Cutting down on the repetitive type identifiers for generics

Re: http://wicket.apache.org

Re: Session Invalidation Options

Re: http://wicket.apache.org

Re: http://wicket.apache.org

http://wicket.apache.org

Re: Session Invalidation Options

Re: Session Invalidation Options

Re: Session Invalidation Options

Session Invalidation Options

Re: if this is true.

if this is true.

Wicket-auth-roles : French translation

Re: Cutting down on the repetitive type identifiers for generics

Re: Cutting down on the repetitive type identifiers for generics

Re: Cutting down on the repetitive type identifiers for generics

Re: Cutting down on the repetitive type identifiers for generics

WICKET-1355 autocomplete positioning

Re: Cutting down on the repetitive type identifiers for generics

Cutting down on the repetitive type identifiers for generics

Re: Wicket Stuff commit access

Wicket Stuff commit access

Re: Patch for easy Enums I18N

Re: Patch for easy Enums I18N

Re: Patch for easy Enums I18N

Re: Patch for easy Enums I18N

Re: Patch for easy Enums I18N

Re: Patch submitted for Enum-ification of the runtime configuration types

Patch for easy Enums I18N

Re: Patch submitted for Enum-ification of the runtime configuration types

Re: Patch submitted for Enum-ification of the runtime configuration types

Re: Patch submitted for Enum-ification of the runtime configuration types

Re: Patch submitted for Enum-ification of the runtime configuration types

Patch submitted for Enum-ification of the runtime configuration types

PropertyModels without strings