Re: programmatic resources lookup

2015-12-23 Thread Martin Grigorov
Hi,

String xyz = new StringResourceModel(...).getObject();

P.S. I hope it is short enough!
On Dec 24, 2015 2:11 AM, "Garret Wilson"  wrote:

> I've been away from Wicket for a year, working on other areas of my
> client's code. I'm doing a pass by to add i18n to a page. I have a
> MyPage.properties file with all sorts of properties. I have lots of
>  tags in MyPage.html.
>
> But how do I manually look up one of these values from the resources? For
> example, in MyPage.onAccept() I have something like this:
>
> getSession().success("Successfully munged the " + fooBar + ".");
>
> I want to look up the value from MyPage.properties:
>
> success.message=Successfully munged the {0}.
>
> Looking at the source code of StringResourceModel, it seems I'll have to
> do the following:
>
> 1. Get a localizer.
> 2. Ask the localizer to get the resource string.
> 3. Escape single quotes.
> 4. Escape substitution expressions (e.g. ${some.other.property}).
> 5. Use MessageFormat to substitute the parameters (e.g. fooBar, above).
> 6. Unescape the substitution expression.
> 7. Ask the localizer to perform substitution for all the expressions.
>
>
> Whew! I'm exhausted just writing that. Surely there is a utility method
> that would do that for me?
>
> Garret
>
> P.S. A /single/ method. There should be a single method for this.
>
>


programmatic resources lookup

2015-12-23 Thread Garret Wilson
I've been away from Wicket for a year, working on other areas of my 
client's code. I'm doing a pass by to add i18n to a page. I have a 
MyPage.properties file with all sorts of properties. I have lots of 
 tags in MyPage.html.


But how do I manually look up one of these values from the resources? 
For example, in MyPage.onAccept() I have something like this:


getSession().success("Successfully munged the " + fooBar + ".");

I want to look up the value from MyPage.properties:

success.message=Successfully munged the {0}.

Looking at the source code of StringResourceModel, it seems I'll have to 
do the following:


1. Get a localizer.
2. Ask the localizer to get the resource string.
3. Escape single quotes.
4. Escape substitution expressions (e.g. ${some.other.property}).
5. Use MessageFormat to substitute the parameters (e.g. fooBar, above).
6. Unescape the substitution expression.
7. Ask the localizer to perform substitution for all the expressions.


Whew! I'm exhausted just writing that. Surely there is a utility method 
that would do that for me?


Garret

P.S. A /single/ method. There should be a single method for this.



Re: Native WebSockets - cookies and last handler question

2015-12-23 Thread Daniel Stoch
On Wed, Dec 23, 2015 at 3:41 PM, Martin Grigorov  wrote:
> On Wed, Dec 23, 2015 at 2:52 PM, Daniel Stoch 
> wrote:
>
>> On Wed, Dec 23, 2015 at 2:34 PM, Martin Grigorov 
>> wrote:
>> > Hi,
>> >
>> >
>> > On Wed, Dec 23, 2015 at 2:21 PM, Daniel Stoch 
>> > wrote:
>> >
>> >> Hi,
>> >>
>> >> I am during replacement Atmosphere push implementation to Wicket
>> >> Native WebSockets. I have an abstraction layer over it, so I can
>> >> replace only implementation and easily switch between these two
>> >> solutions and compare them. I have a couple of questions about Native
>> >> WebSockets:
>> >>
>> >> 1. In WebSocketResponse many methods throws
>> >> UnsupportedOperationException. I have a situation when component sets
>> >> cookie during its lifecycle, so this exeption is raised when it is
>> >> refreshed during push response. Is it any chance to implement these
>> >> methods or do they necessary throw exceptions? In Atmosphere
>> >> implementation this works.
>> >>
>> >
>> > Although an HTTP request is being *upgraded* to WebSocket, the websocket
>> > response is not an HTTP response.
>> > You can only write String and binary data that is processed by the
>> > application client code. The browser doesn't read/intercept the data
>> > transfered on the websocket connection so any headers (like cookies)
>> could
>> > not be processed.
>> >
>> > We could change the impl to log a warning whenever one of those methods
>> is
>> > used instead of throwing exception.
>> > Just like
>> >
>> https://github.com/apache/wicket/commit/8a5508e117991faf43f53d770b64568842d8d557
>> > Please file a ticket if you think this is a better implementation.
>>
>> Logging a warning is not a good solution in my case, because when I
>> call addCookie() I don't know if current response implementation
>> supports it or not (to avoid logging warns). So there will be many
>> unnecessary WARN logs in my application. So a better solution for me
>> is simply do nothing (empty mehod). I think it is probably not a good
>> solution for you, but as I can see in WICKET-5737 there is a factory
>> method for the WebSocketResponse so I will be able to use my own
>> implementation of WebSocketResponse where addCookie() will not throws
>> exception.
>> Can this patch be backported to 6.x?
>>
>
> Sure. Please file a ticket.

WICKET-6054


>> >> 2. I have a code which checks
>> >> PageRequestHandlerTracker.getLastHandler(requestCycle) to get actual
>> >> page for current request (is it a best method?). During processing
>> >> push request this method returns null. Is it a correct behavior? In
>> >> Atmosphere implementation this works too ;).
>> >>
>> >
>> > I think this should work.
>> > There must be a bug somewhere.
>>
>> What should I check, how to investigate it?
>>
>
> Put a breakpoint at
> https://github.com/apache/wicket/blob/master/wicket-native-websocket/wicket-native-websocket-core/src/main/java/org/apache/wicket/protocol/ws/api/AbstractWebSocketProcessor.java#L237
> and see why the request cycle listeners are not notified.

This probably has been fixed in WICKET-5701 (in 6.18.0). I am using
6.17.0 and there is not scheduleRequestHandlerAfterCurrent() call.
So I have to upgrade and then check if it works ok.

Thanks for your help!

--
Best regards,
Daniel

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: Native WebSockets - cookies and last handler question

2015-12-23 Thread Martin Grigorov
On Wed, Dec 23, 2015 at 2:52 PM, Daniel Stoch 
wrote:

> On Wed, Dec 23, 2015 at 2:34 PM, Martin Grigorov 
> wrote:
> > Hi,
> >
> >
> > On Wed, Dec 23, 2015 at 2:21 PM, Daniel Stoch 
> > wrote:
> >
> >> Hi,
> >>
> >> I am during replacement Atmosphere push implementation to Wicket
> >> Native WebSockets. I have an abstraction layer over it, so I can
> >> replace only implementation and easily switch between these two
> >> solutions and compare them. I have a couple of questions about Native
> >> WebSockets:
> >>
> >> 1. In WebSocketResponse many methods throws
> >> UnsupportedOperationException. I have a situation when component sets
> >> cookie during its lifecycle, so this exeption is raised when it is
> >> refreshed during push response. Is it any chance to implement these
> >> methods or do they necessary throw exceptions? In Atmosphere
> >> implementation this works.
> >>
> >
> > Although an HTTP request is being *upgraded* to WebSocket, the websocket
> > response is not an HTTP response.
> > You can only write String and binary data that is processed by the
> > application client code. The browser doesn't read/intercept the data
> > transfered on the websocket connection so any headers (like cookies)
> could
> > not be processed.
> >
> > We could change the impl to log a warning whenever one of those methods
> is
> > used instead of throwing exception.
> > Just like
> >
> https://github.com/apache/wicket/commit/8a5508e117991faf43f53d770b64568842d8d557
> > Please file a ticket if you think this is a better implementation.
>
> Logging a warning is not a good solution in my case, because when I
> call addCookie() I don't know if current response implementation
> supports it or not (to avoid logging warns). So there will be many
> unnecessary WARN logs in my application. So a better solution for me
> is simply do nothing (empty mehod). I think it is probably not a good
> solution for you, but as I can see in WICKET-5737 there is a factory
> method for the WebSocketResponse so I will be able to use my own
> implementation of WebSocketResponse where addCookie() will not throws
> exception.
> Can this patch be backported to 6.x?
>

Sure. Please file a ticket.


>
>
> >
> >>
> >> 2. I have a code which checks
> >> PageRequestHandlerTracker.getLastHandler(requestCycle) to get actual
> >> page for current request (is it a best method?). During processing
> >> push request this method returns null. Is it a correct behavior? In
> >> Atmosphere implementation this works too ;).
> >>
> >
> > I think this should work.
> > There must be a bug somewhere.
>
> What should I check, how to investigate it?
>

Put a breakpoint at
https://github.com/apache/wicket/blob/master/wicket-native-websocket/wicket-native-websocket-core/src/main/java/org/apache/wicket/protocol/ws/api/AbstractWebSocketProcessor.java#L237
and see why the request cycle listeners are not notified.


>
>
> >
> >
> >>
> >> More questions to come later ;)
> >> PS. I am using Wicket 6.x.
> >>
> >> --
> >> Best regards,
> >> Daniel
> >>
> >> -
> >> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> >> For additional commands, e-mail: users-h...@wicket.apache.org
> >>
> >>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>


Re: Native WebSockets - cookies and last handler question

2015-12-23 Thread Daniel Stoch
On Wed, Dec 23, 2015 at 2:34 PM, Martin Grigorov  wrote:
> Hi,
>
>
> On Wed, Dec 23, 2015 at 2:21 PM, Daniel Stoch 
> wrote:
>
>> Hi,
>>
>> I am during replacement Atmosphere push implementation to Wicket
>> Native WebSockets. I have an abstraction layer over it, so I can
>> replace only implementation and easily switch between these two
>> solutions and compare them. I have a couple of questions about Native
>> WebSockets:
>>
>> 1. In WebSocketResponse many methods throws
>> UnsupportedOperationException. I have a situation when component sets
>> cookie during its lifecycle, so this exeption is raised when it is
>> refreshed during push response. Is it any chance to implement these
>> methods or do they necessary throw exceptions? In Atmosphere
>> implementation this works.
>>
>
> Although an HTTP request is being *upgraded* to WebSocket, the websocket
> response is not an HTTP response.
> You can only write String and binary data that is processed by the
> application client code. The browser doesn't read/intercept the data
> transfered on the websocket connection so any headers (like cookies) could
> not be processed.
>
> We could change the impl to log a warning whenever one of those methods is
> used instead of throwing exception.
> Just like
> https://github.com/apache/wicket/commit/8a5508e117991faf43f53d770b64568842d8d557
> Please file a ticket if you think this is a better implementation.

Logging a warning is not a good solution in my case, because when I
call addCookie() I don't know if current response implementation
supports it or not (to avoid logging warns). So there will be many
unnecessary WARN logs in my application. So a better solution for me
is simply do nothing (empty mehod). I think it is probably not a good
solution for you, but as I can see in WICKET-5737 there is a factory
method for the WebSocketResponse so I will be able to use my own
implementation of WebSocketResponse where addCookie() will not throws
exception.
Can this patch be backported to 6.x?


>
>>
>> 2. I have a code which checks
>> PageRequestHandlerTracker.getLastHandler(requestCycle) to get actual
>> page for current request (is it a best method?). During processing
>> push request this method returns null. Is it a correct behavior? In
>> Atmosphere implementation this works too ;).
>>
>
> I think this should work.
> There must be a bug somewhere.

What should I check, how to investigate it?


>
>
>>
>> More questions to come later ;)
>> PS. I am using Wicket 6.x.
>>
>> --
>> Best regards,
>> Daniel
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>> For additional commands, e-mail: users-h...@wicket.apache.org
>>
>>

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: Native WebSockets - cookies and last handler question

2015-12-23 Thread Martin Grigorov
Hi,


On Wed, Dec 23, 2015 at 2:21 PM, Daniel Stoch 
wrote:

> Hi,
>
> I am during replacement Atmosphere push implementation to Wicket
> Native WebSockets. I have an abstraction layer over it, so I can
> replace only implementation and easily switch between these two
> solutions and compare them. I have a couple of questions about Native
> WebSockets:
>
> 1. In WebSocketResponse many methods throws
> UnsupportedOperationException. I have a situation when component sets
> cookie during its lifecycle, so this exeption is raised when it is
> refreshed during push response. Is it any chance to implement these
> methods or do they necessary throw exceptions? In Atmosphere
> implementation this works.
>

Although an HTTP request is being *upgraded* to WebSocket, the websocket
response is not an HTTP response.
You can only write String and binary data that is processed by the
application client code. The browser doesn't read/intercept the data
transfered on the websocket connection so any headers (like cookies) could
not be processed.

We could change the impl to log a warning whenever one of those methods is
used instead of throwing exception.
Just like
https://github.com/apache/wicket/commit/8a5508e117991faf43f53d770b64568842d8d557
Please file a ticket if you think this is a better implementation.


>
> 2. I have a code which checks
> PageRequestHandlerTracker.getLastHandler(requestCycle) to get actual
> page for current request (is it a best method?). During processing
> push request this method returns null. Is it a correct behavior? In
> Atmosphere implementation this works too ;).
>

I think this should work.
There must be a bug somewhere.


>
> More questions to come later ;)
> PS. I am using Wicket 6.x.
>
> --
> Best regards,
> Daniel
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>


Native WebSockets - cookies and last handler question

2015-12-23 Thread Daniel Stoch
Hi,

I am during replacement Atmosphere push implementation to Wicket
Native WebSockets. I have an abstraction layer over it, so I can
replace only implementation and easily switch between these two
solutions and compare them. I have a couple of questions about Native
WebSockets:

1. In WebSocketResponse many methods throws
UnsupportedOperationException. I have a situation when component sets
cookie during its lifecycle, so this exeption is raised when it is
refreshed during push response. Is it any chance to implement these
methods or do they necessary throw exceptions? In Atmosphere
implementation this works.

2. I have a code which checks
PageRequestHandlerTracker.getLastHandler(requestCycle) to get actual
page for current request (is it a best method?). During processing
push request this method returns null. Is it a correct behavior? In
Atmosphere implementation this works too ;).

More questions to come later ;)
PS. I am using Wicket 6.x.

--
Best regards,
Daniel

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: Problem with

2015-12-23 Thread Martin Grigorov
Hi,

This is a CSS question.
It is caused by the "display:flex" on the 'ul'.
I have no idea what is the fix though.


On Tue, Dec 22, 2015 at 8:40 PM, Malte Neumann  wrote:

> 
> 
> 
> ul {
> list-style-type: none;
> display: flex;
> flex-wrap: wrap;
> }
>
> li {
> border: solid red thin;
> width: 25vw;
> }
> 
> 
> 
>
> 
> Item 1
> Item 2
> Item 3
> Item 4
> 
> 
> Item 1
> 
> Item 2
> Item 3
> Item 4
> 
> 
>
> 
> 
>



Martin Grigorov
Wicket Training and Consulting
https://twitter.com/mtgrigorov