date:20080919

Though afaik the URL encryption will be even better with 1.3.5, where
the encryption key is session-based, that is, per user, instead of one
default key for everything (current 1.3.4 behaviour).

Once that is released, you get unique-per-user URLs which provide
perfect protection against CSRF without ever getting into the way of
the application developer. Haven't seen that anywhere else!

Jörn

On Thu, Sep 18, 2008 at 7:15 PM, Jonathan Locke
[EMAIL PROTECTED] wrote:


 to be totally explicit, the third sentence should probably say explicit
 steps must be taken *by the programmer* ;-)

 the last sentence is outdated as wicket provides URL encryption if you want
 it


 Johan Compagner wrote:

 Why is that sentence ambiguous?

 On 9/18/08, cj91 [EMAIL PROTECTED] wrote:

 My company is planning an extremely large web project and Wicket is a
 candidate for use. My manager pointed out some unsettling words on the
 Wicket FAQ, which are ambiguous unfortunately.
 http://wicket.apache.org/features.html

Wicket is secure by default. URLs do not expose sensitive information
 and
 all component paths are
session-relative. Explicit steps must be taken to share information
 between sessions. There are plans
for the next version of Wicket to add URL encryption to support highly
 secure web sites.


 Can someone please elaborate on what is meant by Explicit steps must be
 taken to share information between sessions.

 Thank you,
 -Jonathan
 --
 View this message in context:
 http://www.nabble.com/Wicket-not-secure--tp19556259p19556259.html
 Sent from the Wicket - User mailing list archive at Nabble.com.


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



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




 --
 View this message in context: 
 http://www.nabble.com/Wicket-not-secure--tp19556259p19557667.html
 Sent from the Wicket - User mailing list archive at Nabble.com.


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

Re: Does StringResouceModel support html tags

2008-09-19 Thread Murat Yücel

Damn it works. Sorry for bothering the list. I probably tried to many things
last night.
Well thanks for the help :)

2008/9/19 Murat Yücel [EMAIL PROTECTED]

 I have set the flag but it still doesnt work. Can you confirmed this on
 your side?

 /Murat

 2008/9/19 Michael Sparer [EMAIL PROTECTED]


 setEscapeModelStrings to false on your component (e.g. Label) and it
 should
 work


 Murat Yücel-2 wrote:
 
  Hi All
 
  First of all i am using wicket 1.3.4. I have a problem with not being
 able
  to show html characters when using
  StringResourceModel together with xml property file. Xml property file
  doesnt support html tags because it
  not valid in an xml file. I have tried to escape the  tag but then i
  will
  just see the text as it is. For example
  if the text is entry key=test.keylt;bgt;Testlt;/bgt;/entry
 then
  is
  will just show Test on the screen.
 
  I then thought that it might be possible to give html characters as
  parameters. For example:
  entry key=test.keyYou have selected {0}/entry
 
  Then i will give the parameter Test to the StringResourceModel, but
  still no luck.
 
  I have set the method Label.setEscapeModelStrings(false) but it seems
 like
  it doesnt have any effect.
 
  Hope that you can help.
 
  Kind regards
 
  /Murat
 
 


 -
 Michael Sparer
 http://talk-on-tech.blogspot.com
 --
 View this message in context:
 http://www.nabble.com/Does-StringResouceModel-support-html-tags-tp19567229p19567583.html
 Sent from the Wicket - User mailing list archive at Nabble.com.


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

onmouseover image

2008-09-19 Thread Tim Squires

Hi All,

Before I go and write my own component to change the src of an img
onouseover, I just wanted to make sure that there is no standard
component.  I don't want to re-invent the wheel.

Is there a standard component for changing the Image or ImageButton image
onmouseover?

Thanks,
Tim


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

setResponsePage(Page) and back button

2008-09-19 Thread Kristof Jozsa

Hi,

I'd love to use setResponsePage(Page) (so redirecting to a concrete
page instance instead of a page class) on handling standard (non-ajax)
links in my application. I found it very handy to use the actual model
objects in their current state, instantiate the new page object
passing the current models and set them as the response page, like
this:

public void onClick() {
setResponsePage(new MySubPage(anyCurrentModelObject));
}

Unfortunately, every time I use the back button and trying to click on
links again, I get a page expiration. Is there any way around this?

I don't claim this being a problem, there might be a rational reason
for this behaviour, but passing current model objects this way would
be much more handy than using page parameters and rebuilding models on
the new page from scratch. Can I somehow accomplish this?

thanks,
Kristof

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

Re: setResponsePage(Page) and back button

2008-09-19 Thread Martijn Dashorst

Avast! Did ye check furr t' nasty serialization errs? Them could sink
a mighty ship and cause them pesky expiration pages.

Capt'n McDasmans

(t'is Internation'l Talk Like a pirate day t'day matey!)
http://talklikeapirate.com

On Fri, Sep 19, 2008 at 11:36 AM, Kristof Jozsa [EMAIL PROTECTED] wrote:
 Hi,

 I'd love to use setResponsePage(Page) (so redirecting to a concrete
 page instance instead of a page class) on handling standard (non-ajax)
 links in my application. I found it very handy to use the actual model
 objects in their current state, instantiate the new page object
 passing the current models and set them as the response page, like
 this:

 public void onClick() {
setResponsePage(new MySubPage(anyCurrentModelObject));
 }

 Unfortunately, every time I use the back button and trying to click on
 links again, I get a page expiration. Is there any way around this?

 I don't claim this being a problem, there might be a rational reason
 for this behaviour, but passing current model objects this way would
 be much more handy than using page parameters and rebuilding models on
 the new page from scratch. Can I somehow accomplish this?

 thanks,
 Kristof

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





-- 
Become a Wicket expert, learn from the best: http://wicketinaction.com
Apache Wicket 1.3.4 is released
Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.

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

Re: setResponsePage(Page) and back button

2008-09-19 Thread Kristof Jozsa

Damn, you be starboard! Removin' t' only known unserializable booty
from me base page class immediately solved t' problem. I bow before
your mightyness, captain!

Kristof Threapwood

On Fri, Sep 19, 2008 at 11:41 AM, Martijn Dashorst
[EMAIL PROTECTED] wrote:
 Avast! Did ye check furr t' nasty serialization errs? Them could sink
 a mighty ship and cause them pesky expiration pages.

 Capt'n McDasmans

 (t'is Internation'l Talk Like a pirate day t'day matey!)
 http://talklikeapirate.com

 On Fri, Sep 19, 2008 at 11:36 AM, Kristof Jozsa [EMAIL PROTECTED] wrote:
 Hi,

 I'd love to use setResponsePage(Page) (so redirecting to a concrete
 page instance instead of a page class) on handling standard (non-ajax)
 links in my application. I found it very handy to use the actual model
 objects in their current state, instantiate the new page object
 passing the current models and set them as the response page, like
 this:

 public void onClick() {
setResponsePage(new MySubPage(anyCurrentModelObject));
 }

 Unfortunately, every time I use the back button and trying to click on
 links again, I get a page expiration. Is there any way around this?

 I don't claim this being a problem, there might be a rational reason
 for this behaviour, but passing current model objects this way would
 be much more handy than using page parameters and rebuilding models on
 the new page from scratch. Can I somehow accomplish this?

 thanks,
 Kristof

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





 --
 Become a Wicket expert, learn from the best: http://wicketinaction.com
 Apache Wicket 1.3.4 is released
 Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.

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



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

1.4M4?

2008-09-19 Thread Stefan Lindner

Wicket in Action is out, the open issues for 1.4 are constantly decreasing. Is 
a 1.4M4 in sight?

Stefan

Ajax-only-Form?

2008-09-19 Thread Markus

Hi all,

 

I have an issue with a Form I want only to be available to users with
Javascript turned on, so I used a AjaxButton, and set DefaultButton to the
AjaxButton. 

But the Form still submits using 'Return' - rendering the Body only also
kills the AjaxButton.  Can anyone help me how to achieve this? Hiding the
Button and appending a onchange-event to the first input-field is in my
opinion a very bad way of doing it. Also in-page javascripting seems not
so nice.

 

Regards

Markus

Wicketstuff wishlist?

2008-09-19 Thread Nino Saturnino Martinez Vazquez Wael


Hi

I'd really like a wish list for wicketstuff. So reply with your wishes 
and I might have time at a point to implement it:)


I'll start by adding this to the list:

Integration with :  http://code.google.com/p/iui/


I'll add a wishlist to the wiki or maybe my blog..

--
-Wicket for love

Nino Martinez Wael
Java Specialist @ Jayway DK
http://www.jayway.dk
+45 2936 7684


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

Re: Transactions..... again!

On Thu, Sep 18, 2008 at 11:20 PM, Igor Vaynberg [EMAIL PROTECTED] wrote:
 aspectj is pretty cool, but its expression language is somewhat
 limited. for example salve allows

 public void somefunction(@NotNull Integer a, @NotEmpty String b) {}

 aspectj, at least when i started salve, did not have an expression
 that would let you match a function if its argument was annotated with
 a specific annot.

Point taken.  I'm not sure about this particular case, but I know the
annotation support for AspectJ has been improved.


 also i need things like removing/adding fields and contributing to
 clinit. aspectj is great for quickly matching on something and then
 adding something around, not for complex bytecode manipulation.

AspectJ can add in fields, but it's not good at adding in a
dynamically-generated set of fields.


 i started out writing salve with javassist, but i got tired of writing
 java code in strings. i wanted to be in complete control of bytecode
 to make sure it was as efficient as possible so in the end i learned a
 bit about bytecode and ended up using ASM.

Javassist can be a big PITA at first.  The HiveMind project has helper
classes around it to assist with stuff, but it was still confusing.
That's one of the reasons I wrote Apache Commons Proxy, so I wouldn't
have to write another bit of Javassist to do proxying! :)

Thanks for taking the time to discuss.  I'm going to have to check out
Salve a bit more in-depth.  It's going into my Geek Queue! :)

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

Re: setResponsePage(Page) and back button

Since it's International Talk Like a Pirate Day:

A pirate walks into a bar with a steering wheel hanging out his
zipper.  The bartender says hey, buddy, did you know you've got a
steering wheel hanging out your zipper?  The pirate says A!  And
it's drivin' me nuts

On Fri, Sep 19, 2008 at 5:50 AM, Kristof Jozsa [EMAIL PROTECTED] wrote:
 Damn, you be starboard! Removin' t' only known unserializable booty
 from me base page class immediately solved t' problem. I bow before
 your mightyness, captain!

 Kristof Threapwood

 On Fri, Sep 19, 2008 at 11:41 AM, Martijn Dashorst
 [EMAIL PROTECTED] wrote:
 Avast! Did ye check furr t' nasty serialization errs? Them could sink
 a mighty ship and cause them pesky expiration pages.

 Capt'n McDasmans

 (t'is Internation'l Talk Like a pirate day t'day matey!)
 http://talklikeapirate.com

 On Fri, Sep 19, 2008 at 11:36 AM, Kristof Jozsa [EMAIL PROTECTED] wrote:
 Hi,

 I'd love to use setResponsePage(Page) (so redirecting to a concrete
 page instance instead of a page class) on handling standard (non-ajax)
 links in my application. I found it very handy to use the actual model
 objects in their current state, instantiate the new page object
 passing the current models and set them as the response page, like
 this:

 public void onClick() {
setResponsePage(new MySubPage(anyCurrentModelObject));
 }

 Unfortunately, every time I use the back button and trying to click on
 links again, I get a page expiration. Is there any way around this?

 I don't claim this being a problem, there might be a rational reason
 for this behaviour, but passing current model objects this way would
 be much more handy than using page parameters and rebuilding models on
 the new page from scratch. Can I somehow accomplish this?

 thanks,
 Kristof

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





 --
 Become a Wicket expert, learn from the best: http://wicketinaction.com
 Apache Wicket 1.3.4 is released
 Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.

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



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



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

Markup for disabled Link - Proposal (add behavior instead of markup)

Dear Wicket devs,

I propose that by default a disabled link should rather (or also) be marked
using a behavior, instead of adding markup before and after.

A word in advance: I know that I can implement my own version of Link which
adds behavior in case of being disabled, and I know how to do it - this is
not a cry for help, just a proposal, how I think the Link component should
behave to fit most common use cases. The current way simple does not feel
right.

Why do I think so? When creating a template, most people tend to display a
disabled status of an element by appending a css class to its tag, you can
see class=disabled very often, making colors gray or applying
transparency.
IMHO something like this should not be done by changing the DOM hierarchy of
the element.

Example: a Link with an arrow image (CSS background) - quite common. It is
not (at least as easy as it should be) possible to have another image for a
disabled link with this behavior, since there is nothing like an
if-element-has-child-element-selector in CSS.

Besides (I know it is configurable, but...) : I am not sure why one would
want to [em]phasize something that's disabled ;-)

I would love to see a defaultDisabledLinkBehavior property in future
versions, this would make it a lot easier to style disabled links...

Cheers + best regards :)

--
View this message in context:
http://www.nabble.com/Markup-for-disabled-Link---Proposal-%28add-behavior-instead-of-markup%29-tp19570584p19570584.html
Sent from the Wicket - User mailing list archive at Nabble.com.

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

Re: AW: Wicket and Mootools?

2008-09-19 Thread Nino Saturnino Martinez Vazquez Wael




Agent Mahone wrote:

O, thank u very much for ur comments.

I have some questions to you:

1. What is the package mini under contribution package for?
What is the difference to package contribution/wicket-mootools???
  

Im not sure how well managed wicket-mootools are...

2. I also noticed that wicket offers you scriptaculous and jquery.
   Is there any comparsion between that frameworks?
  

Go google:)

I´ve seen that scriptaculous is much more easier to understand and difinitely 
to use.

Thanks again for any comments





- Ursprüngliche Mail 
Von: Nino Saturnino Martinez Vazquez Wael [EMAIL PROTECTED]
An: users@wicket.apache.org
Gesendet: Donnerstag, den 18. September 2008, 09:50:32 Uhr
Betreff: Re: Wicket and Mootools?

You can also check out the new addition to wicket stuff minis, the 
mootips integration..


Agent Mahone wrote:
  

Hi all

What is the best way to integrate mootools in wicket ?

Does Mootools slow down the application? Does somebody had good expierence with 
it?

Thanks in advane for any comments


__
Do You Yahoo!?
Sie sind Spam leid? Yahoo! Mail verfügt über einen herausragenden Schutz gegen Massenmails. 
http://mail.yahoo.com 
 



  


--
-Wicket for love

Nino Martinez Wael
Java Specialist @ Jayway DK
http://www.jayway.dk
+45 2936 7684


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

Re: Wicketstuff wishlist?

Don't we have already at least one wishlist on the wicket wiki?
http://cwiki.apache.org/WICKET/#Index-WishListforNextVersion

Jörn

On Fri, Sep 19, 2008 at 12:30 PM, Nino Saturnino Martinez Vazquez Wael
[EMAIL PROTECTED] wrote:
 Hi

 I'd really like a wish list for wicketstuff. So reply with your wishes and I
 might have time at a point to implement it:)

 I'll start by adding this to the list:

 Integration with :  http://code.google.com/p/iui/


 I'll add a wishlist to the wiki or maybe my blog..

 --
 -Wicket for love

 Nino Martinez Wael
 Java Specialist @ Jayway DK
 http://www.jayway.dk
 +45 2936 7684


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

Re: Markup for disabled Link - Proposal (add behavior instead of markup)

2008-09-19 Thread Nino Saturnino Martinez Vazquez Wael


Why not just use an attribute modifier?

pixologe wrote:

Dear Wicket devs,

I propose that by default a disabled link should rather (or also) be marked
using a behavior, instead of adding markup before and after.

A word in advance: I know that I can implement my own version of Link which
adds behavior in case of being disabled, and I know how to do it - this is
not a cry for help, just a proposal, how I think the Link component should
behave to fit most common use cases. The current way simple does not feel
right.

Why do I think so? When creating a template, most people tend to display a
disabled status of an element by appending a css class to its tag, you can
see class=disabled very often, making colors gray or applying
transparency. 
IMHO something like this should not be done by changing the DOM hierarchy of

the element.

Example: a Link with an arrow image (CSS background) - quite common. It is
not (at least as easy as it should be) possible to have another image for a
disabled link with this behavior, since there is nothing like an
if-element-has-child-element-selector in CSS.

Besides (I know it is configurable, but...) : I am not sure why one would
want to [em]phasize something that's disabled ;-)

I would love to see a defaultDisabledLinkBehavior property in future
versions, this would make it a lot easier to style disabled links...

Cheers + best regards :)

  


--
-Wicket for love

Nino Martinez Wael
Java Specialist @ Jayway DK
http://www.jayway.dk
+45 2936 7684


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

Re: Wicketstuff wishlist?

2008-09-19 Thread Nino Saturnino Martinez Vazquez Wael


wicketstuff!=wicket :)

And it should not go on the wicket wiki...

Jörn Zaefferer wrote:

Don't we have already at least one wishlist on the wicket wiki?
http://cwiki.apache.org/WICKET/#Index-WishListforNextVersion

Jörn

On Fri, Sep 19, 2008 at 12:30 PM, Nino Saturnino Martinez Vazquez Wael
[EMAIL PROTECTED] wrote:
  

Hi

I'd really like a wish list for wicketstuff. So reply with your wishes and I
might have time at a point to implement it:)

I'll start by adding this to the list:

Integration with :  http://code.google.com/p/iui/


I'll add a wishlist to the wiki or maybe my blog..

--
-Wicket for love

Nino Martinez Wael
Java Specialist @ Jayway DK
http://www.jayway.dk
+45 2936 7684


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





--
-Wicket for love

Nino Martinez Wael
Java Specialist @ Jayway DK
http://www.jayway.dk
+45 2936 7684


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

Re: Markup for disabled Link - Proposal (add behavior instead of markup)

Actually that is what I do. That's what I meant when I said implement own
version... Basically it extends AjaxFallbackLink overriding onBeforeRender
to add a Modifier dependent on the enabled property.

Just wanted to point out that this is the behavior I would have expected by
default, instead of having the page hierarchy modified and the link
displayed in italics...

Nino.Martinez wrote:

Why not just use an attribute modifier?

pixologe wrote:
Dear Wicket devs,

I propose that by default a disabled link should rather (or also) be
marked
using a behavior, instead of adding markup before and after.

A word in advance: I know that I can implement my own version of Link
which
adds behavior in case of being disabled, and I know how to do it - this
is
not a cry for help, just a proposal, how I think the Link component
should
behave to fit most common use cases. The current way simple does not feel
right.

Why do I think so? When creating a template, most people tend to display
a
disabled status of an element by appending a css class to its tag, you
can
see class=disabled very often, making colors gray or applying
transparency.
IMHO something like this should not be done by changing the DOM hierarchy
of
the element.

Example: a Link with an arrow image (CSS background) - quite common. It
is
not (at least as easy as it should be) possible to have another image for
a
disabled link with this behavior, since there is nothing like an
if-element-has-child-element-selector in CSS.

Besides (I know it is configurable, but...) : I am not sure why one would
want to [em]phasize something that's disabled ;-)

I would love to see a defaultDisabledLinkBehavior property in future
versions, this would make it a lot easier to style disabled links...

Cheers + best regards :)

--
-Wicket for love

Nino Martinez Wael
Java Specialist @ Jayway DK
http://www.jayway.dk
+45 2936 7684

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

--
View this message in context:
http://www.nabble.com/Markup-for-disabled-Link---Proposal-%28add-behavior-instead-of-markup%29-tp19570584p19571503.html
Sent from the Wicket - User mailing list archive at Nabble.com.

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

Re: Ajax-only-Form?

2008-09-19 Thread richardwilko


So if im understanding correctly your form is submitting in the non-ajax
standard way when you press return on the input field?

If so then this is my solution:

http://www.richard-wilkinson.co.uk/2008/04/05/how-to-stop-non-ajax-form-submits-in-wicket/

Hope it helps,

Richard



Markus-66 wrote:
 
 Hi all,
 
  
 
 I have an issue with a Form I want only to be available to users with
 Javascript turned on, so I used a AjaxButton, and set DefaultButton to the
 AjaxButton. 
 
 But the Form still submits using 'Return' - rendering the Body only also
 kills the AjaxButton.  Can anyone help me how to achieve this? Hiding the
 Button and appending a onchange-event to the first input-field is in my
 opinion a very bad way of doing it. Also in-page javascripting seems not
 so nice.
 
  
 
 Regards
 
 Markus
 
 
 


-
http://www.richard-wilkinson.co.uk My blog:
http://www.richard-wilkinson.co.uk 
-- 
View this message in context: 
http://www.nabble.com/Ajax-only-Form--tp19569839p19571913.html
Sent from the Wicket - User mailing list archive at Nabble.com.


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

Re: Ajax-only-Form?

2008-09-19 Thread Markus

Hi Richard,

thank you for your answer. But my Problem is, I want to cut out the people
with JavaScript deactivated because they cannot use the
GoogleMaps-functionality, what makes it kinda useless to submit the form.
Your prototype-approach won´t work that way.

Perhaps I only add a warning-div on the top and do nothing. Any further
ideas would be appreaciated.

Regards
Markus

-Ursprüngliche Nachricht-
Von: richardwilko [mailto:[EMAIL PROTECTED] 
Gesendet: Freitag, 19. September 2008 15:01
An: users@wicket.apache.org
Betreff: Re: Ajax-only-Form?


So if im understanding correctly your form is submitting in the non-ajax
standard way when you press return on the input field?

If so then this is my solution:

http://www.richard-wilkinson.co.uk/2008/04/05/how-to-stop-non-ajax-form-subm
its-in-wicket/

Hope it helps,

Richard



Markus-66 wrote:
 
 Hi all,
 
  
 
 I have an issue with a Form I want only to be available to users with
 Javascript turned on, so I used a AjaxButton, and set DefaultButton to the
 AjaxButton. 
 
 But the Form still submits using 'Return' - rendering the Body only also
 kills the AjaxButton.  Can anyone help me how to achieve this? Hiding the
 Button and appending a onchange-event to the first input-field is in my
 opinion a very bad way of doing it. Also in-page javascripting seems not
 so nice.
 
  
 
 Regards
 
 Markus
 
 
 


-
http://www.richard-wilkinson.co.uk My blog:
http://www.richard-wilkinson.co.uk 
-- 
View this message in context:
http://www.nabble.com/Ajax-only-Form--tp19569839p19571913.html
Sent from the Wicket - User mailing list archive at Nabble.com.


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



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

Re: Ajax-only-Form?

2008-09-19 Thread richardwilko


In that case use an ajax submit link rather than a button (which uses a href
and an onclick), with no button in the form.

However I dont think this will stop the enter key from submitting the
form...

You could also try lazy loading the form with ajax, that way you can be sure
that if they see the form they have javascript enabled, actually this is
probably the best way of doing it.

Cheers,

Richard



Markus-66 wrote:
 
 Hi Richard,
 
 thank you for your answer. But my Problem is, I want to cut out the
 people
 with JavaScript deactivated because they cannot use the
 GoogleMaps-functionality, what makes it kinda useless to submit the form.
 Your prototype-approach won´t work that way.
 
 Perhaps I only add a warning-div on the top and do nothing. Any further
 ideas would be appreaciated.
 
 Regards
 Markus
 
 -Ursprüngliche Nachricht-
 Von: richardwilko [mailto:[EMAIL PROTECTED] 
 Gesendet: Freitag, 19. September 2008 15:01
 An: users@wicket.apache.org
 Betreff: Re: Ajax-only-Form?
 
 
 So if im understanding correctly your form is submitting in the non-ajax
 standard way when you press return on the input field?
 
 If so then this is my solution:
 
 http://www.richard-wilkinson.co.uk/2008/04/05/how-to-stop-non-ajax-form-subm
 its-in-wicket/
 
 Hope it helps,
 
 Richard
 
 
 
 Markus-66 wrote:
 
 Hi all,
 
  
 
 I have an issue with a Form I want only to be available to users with
 Javascript turned on, so I used a AjaxButton, and set DefaultButton to
 the
 AjaxButton. 
 
 But the Form still submits using 'Return' - rendering the Body only also
 kills the AjaxButton.  Can anyone help me how to achieve this? Hiding the
 Button and appending a onchange-event to the first input-field is in my
 opinion a very bad way of doing it. Also in-page javascripting seems
 not
 so nice.
 
  
 
 Regards
 
 Markus
 
 
 
 
 
 -
 http://www.richard-wilkinson.co.uk My blog:
 http://www.richard-wilkinson.co.uk 
 -- 
 View this message in context:
 http://www.nabble.com/Ajax-only-Form--tp19569839p19571913.html
 Sent from the Wicket - User mailing list archive at Nabble.com.
 
 
 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]
 
 
 
 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]
 
 
 


-
http://www.richard-wilkinson.co.uk My blog:
http://www.richard-wilkinson.co.uk 
-- 
View this message in context: 
http://www.nabble.com/Ajax-only-Form--tp19569839p19572180.html
Sent from the Wicket - User mailing list archive at Nabble.com.


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

AW: Ajax-only-Form?

2008-09-19 Thread Markus

Hi Richard,

that seems a very good idea, thank you, didn´t come into my mind...  *d0h*  ;)

Regards
Markus

-Ursprüngliche Nachricht-
Von: richardwilko [mailto:[EMAIL PROTECTED] 
Gesendet: Freitag, 19. September 2008 15:17
An: users@wicket.apache.org
Betreff: Re: Ajax-only-Form?


In that case use an ajax submit link rather than a button (which uses a href
and an onclick), with no button in the form.

However I dont think this will stop the enter key from submitting the
form...

You could also try lazy loading the form with ajax, that way you can be sure
that if they see the form they have javascript enabled, actually this is
probably the best way of doing it.

Cheers,

Richard



Markus-66 wrote:
 
 Hi Richard,
 
 thank you for your answer. But my Problem is, I want to cut out the
 people
 with JavaScript deactivated because they cannot use the
 GoogleMaps-functionality, what makes it kinda useless to submit the form.
 Your prototype-approach won´t work that way.
 
 Perhaps I only add a warning-div on the top and do nothing. Any further
 ideas would be appreaciated.
 
 Regards
 Markus
 
 -Ursprüngliche Nachricht-
 Von: richardwilko [mailto:[EMAIL PROTECTED] 
 Gesendet: Freitag, 19. September 2008 15:01
 An: users@wicket.apache.org
 Betreff: Re: Ajax-only-Form?
 
 
 So if im understanding correctly your form is submitting in the non-ajax
 standard way when you press return on the input field?
 
 If so then this is my solution:
 
 http://www.richard-wilkinson.co.uk/2008/04/05/how-to-stop-non-ajax-form-subm
 its-in-wicket/
 
 Hope it helps,
 
 Richard
 
 
 
 Markus-66 wrote:
 
 Hi all,
 
  
 
 I have an issue with a Form I want only to be available to users with
 Javascript turned on, so I used a AjaxButton, and set DefaultButton to
 the
 AjaxButton. 
 
 But the Form still submits using 'Return' - rendering the Body only also
 kills the AjaxButton.  Can anyone help me how to achieve this? Hiding the
 Button and appending a onchange-event to the first input-field is in my
 opinion a very bad way of doing it. Also in-page javascripting seems
 not
 so nice.
 
  
 
 Regards
 
 Markus
 
 
 
 
 
 -
 http://www.richard-wilkinson.co.uk My blog:
 http://www.richard-wilkinson.co.uk 
 -- 
 View this message in context:
 http://www.nabble.com/Ajax-only-Form--tp19569839p19571913.html
 Sent from the Wicket - User mailing list archive at Nabble.com.
 
 
 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]
 
 
 
 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]
 
 
 


-
http://www.richard-wilkinson.co.uk My blog:
http://www.richard-wilkinson.co.uk 
-- 
View this message in context: 
http://www.nabble.com/Ajax-only-Form--tp19569839p19572180.html
Sent from the Wicket - User mailing list archive at Nabble.com.


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



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

Re: Wicketstuff wishlist?

Oops, I missed that bit!

Well, then I add: Annotations for form validation. Maybe integrated
with the bean validation JSR, Hibernate Validation or standalone.
Enabled by adding AnnotationValidator instance to a form or indivdual
fields...

Jörn

On Fri, Sep 19, 2008 at 2:05 PM, Nino Saturnino Martinez Vazquez Wael
[EMAIL PROTECTED] wrote:
 wicketstuff!=wicket :)

 And it should not go on the wicket wiki...

 Jörn Zaefferer wrote:

 Don't we have already at least one wishlist on the wicket wiki?
 http://cwiki.apache.org/WICKET/#Index-WishListforNextVersion

 Jörn

 On Fri, Sep 19, 2008 at 12:30 PM, Nino Saturnino Martinez Vazquez Wael
 [EMAIL PROTECTED] wrote:


 Hi

 I'd really like a wish list for wicketstuff. So reply with your wishes
 and I
 might have time at a point to implement it:)

 I'll start by adding this to the list:

 Integration with :  http://code.google.com/p/iui/


 I'll add a wishlist to the wiki or maybe my blog..

 --
 -Wicket for love

 Nino Martinez Wael
 Java Specialist @ Jayway DK
 http://www.jayway.dk
 +45 2936 7684


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




 --
 -Wicket for love

 Nino Martinez Wael
 Java Specialist @ Jayway DK
 http://www.jayway.dk
 +45 2936 7684


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

Java BlackBelt Wicket exam

2008-09-19 Thread Eyal Golan

Hi,
I have proposed to open a Wicket exam in JavaBlackBelt.
Here's my proposal:
http://www.javablackbelt.com/forum/posts/list/0/118.page#567

Please check it and give your thoughts.
I have already written several questions (to myself).

Thanks

-- 
Eyal Golan
[EMAIL PROTECTED]

Visit: http://jvdrums.sourceforge.net/
LinkedIn: http://www.linkedin.com/in/egolan74

P Save a tree. Please don't print this e-mail unless it's really necessary

Disabling RadioGroup via authorization strategy does not disable contained Radio buttons

2008-09-19 Thread Joel Hill

I'm doing some component-based authorization and I'm trying to disable an 
entire RadioGroup without having to tie the authorization to each individual 
Radio button.  Were I to directly disable the RadioGroup, it looks like the 
Radio buttons would also disable (but I haven't tested this); but it will not 
disable all the choices when I tie an authorization strategy to the RadioGroup.

I'm working with wicket 1.3.3, so has this problem been addressed in a later 
versoin, and if not, is there some reason we might not want to do this?

Thanks.

Joel


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

Re: Wicket not secure?

that is trivial to implement with 1.3.4 also

-igor

On Fri, Sep 19, 2008 at 12:51 AM, Jörn Zaefferer
[EMAIL PROTECTED] wrote:
 Though afaik the URL encryption will be even better with 1.3.5, where
 the encryption key is session-based, that is, per user, instead of one
 default key for everything (current 1.3.4 behaviour).

 Once that is released, you get unique-per-user URLs which provide
 perfect protection against CSRF without ever getting into the way of
 the application developer. Haven't seen that anywhere else!

 Jörn

 On Thu, Sep 18, 2008 at 7:15 PM, Jonathan Locke
 [EMAIL PROTECTED] wrote:


 to be totally explicit, the third sentence should probably say explicit
 steps must be taken *by the programmer* ;-)

 the last sentence is outdated as wicket provides URL encryption if you want
 it


 Johan Compagner wrote:

 Why is that sentence ambiguous?

 On 9/18/08, cj91 [EMAIL PROTECTED] wrote:

 My company is planning an extremely large web project and Wicket is a
 candidate for use. My manager pointed out some unsettling words on the
 Wicket FAQ, which are ambiguous unfortunately.
 http://wicket.apache.org/features.html

Wicket is secure by default. URLs do not expose sensitive information
 and
 all component paths are
session-relative. Explicit steps must be taken to share information
 between sessions. There are plans
for the next version of Wicket to add URL encryption to support highly
 secure web sites.


 Can someone please elaborate on what is meant by Explicit steps must be
 taken to share information between sessions.

 Thank you,
 -Jonathan
 --
 View this message in context:
 http://www.nabble.com/Wicket-not-secure--tp19556259p19556259.html
 Sent from the Wicket - User mailing list archive at Nabble.com.


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



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




 --
 View this message in context: 
 http://www.nabble.com/Wicket-not-secure--tp19556259p19557667.html
 Sent from the Wicket - User mailing list archive at Nabble.com.


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




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

Re: Markup for disabled Link - Proposal (add behavior instead of markup)

disabled is more then just about the appearance, if something is
disabled the user should not be able to interact with it. for example,
security strategy can disable links the user does not have access to.
just adding class=disabled leaves the link clickable.

-igor

On Fri, Sep 19, 2008 at 4:21 AM, pixologe [EMAIL PROTECTED] wrote:

Dear Wicket devs,

I propose that by default a disabled link should rather (or also) be marked
using a behavior, instead of adding markup before and after.

Besides (I know it is configurable, but...) : I am not sure why one would
want to [em]phasize something that's disabled ;-)

I would love to see a defaultDisabledLinkBehavior property in future
versions, this would make it a lot easier to style disabled links...

Cheers + best regards :)

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

Re: Wicket not secure?

Sure, but why bother when its already implemented? Security-related
stuff isn't exactly the right place to roll your own.

Jörn

On Fri, Sep 19, 2008 at 4:34 PM, Igor Vaynberg [EMAIL PROTECTED] wrote:
 that is trivial to implement with 1.3.4 also

 -igor

 On Fri, Sep 19, 2008 at 12:51 AM, Jörn Zaefferer
 [EMAIL PROTECTED] wrote:
 Though afaik the URL encryption will be even better with 1.3.5, where
 the encryption key is session-based, that is, per user, instead of one
 default key for everything (current 1.3.4 behaviour).

 Once that is released, you get unique-per-user URLs which provide
 perfect protection against CSRF without ever getting into the way of
 the application developer. Haven't seen that anywhere else!

 Jörn

 On Thu, Sep 18, 2008 at 7:15 PM, Jonathan Locke
 [EMAIL PROTECTED] wrote:


 to be totally explicit, the third sentence should probably say explicit
 steps must be taken *by the programmer* ;-)

 the last sentence is outdated as wicket provides URL encryption if you want
 it


 Johan Compagner wrote:

 Why is that sentence ambiguous?

 On 9/18/08, cj91 [EMAIL PROTECTED] wrote:

 My company is planning an extremely large web project and Wicket is a
 candidate for use. My manager pointed out some unsettling words on the
 Wicket FAQ, which are ambiguous unfortunately.
 http://wicket.apache.org/features.html

Wicket is secure by default. URLs do not expose sensitive information
 and
 all component paths are
session-relative. Explicit steps must be taken to share information
 between sessions. There are plans
for the next version of Wicket to add URL encryption to support highly
 secure web sites.


 Can someone please elaborate on what is meant by Explicit steps must be
 taken to share information between sessions.

 Thank you,
 -Jonathan
 --
 View this message in context:
 http://www.nabble.com/Wicket-not-secure--tp19556259p19556259.html
 Sent from the Wicket - User mailing list archive at Nabble.com.


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



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




 --
 View this message in context: 
 http://www.nabble.com/Wicket-not-secure--tp19556259p19557667.html
 Sent from the Wicket - User mailing list archive at Nabble.com.


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




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

Re: Wicket not secure?

you dont have to roll your own security, just where wicket looks for the key :)

-igor

On Fri, Sep 19, 2008 at 7:40 AM, Jörn Zaefferer
[EMAIL PROTECTED] wrote:
 Sure, but why bother when its already implemented? Security-related
 stuff isn't exactly the right place to roll your own.

 Jörn

 On Fri, Sep 19, 2008 at 4:34 PM, Igor Vaynberg [EMAIL PROTECTED] wrote:
 that is trivial to implement with 1.3.4 also

 -igor

 On Fri, Sep 19, 2008 at 12:51 AM, Jörn Zaefferer
 [EMAIL PROTECTED] wrote:
 Though afaik the URL encryption will be even better with 1.3.5, where
 the encryption key is session-based, that is, per user, instead of one
 default key for everything (current 1.3.4 behaviour).

 Once that is released, you get unique-per-user URLs which provide
 perfect protection against CSRF without ever getting into the way of
 the application developer. Haven't seen that anywhere else!

 Jörn

 On Thu, Sep 18, 2008 at 7:15 PM, Jonathan Locke
 [EMAIL PROTECTED] wrote:


 to be totally explicit, the third sentence should probably say explicit
 steps must be taken *by the programmer* ;-)

 the last sentence is outdated as wicket provides URL encryption if you want
 it


 Johan Compagner wrote:

 Why is that sentence ambiguous?

 On 9/18/08, cj91 [EMAIL PROTECTED] wrote:

 My company is planning an extremely large web project and Wicket is a
 candidate for use. My manager pointed out some unsettling words on the
 Wicket FAQ, which are ambiguous unfortunately.
 http://wicket.apache.org/features.html

Wicket is secure by default. URLs do not expose sensitive information
 and
 all component paths are
session-relative. Explicit steps must be taken to share information
 between sessions. There are plans
for the next version of Wicket to add URL encryption to support highly
 secure web sites.


 Can someone please elaborate on what is meant by Explicit steps must be
 taken to share information between sessions.

 Thank you,
 -Jonathan
 --
 View this message in context:
 http://www.nabble.com/Wicket-not-secure--tp19556259p19556259.html
 Sent from the Wicket - User mailing list archive at Nabble.com.


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



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




 --
 View this message in context: 
 http://www.nabble.com/Wicket-not-secure--tp19556259p19557667.html
 Sent from the Wicket - User mailing list archive at Nabble.com.


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




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




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

Re: Java BlackBelt Wicket exam

2008-09-19 Thread Nino Saturnino Martinez Vazquez Wael


Hi

It looks fairly simple, I guess it depends on the depth of the exam... 
Because it could go over a lot more, or maybe the points could specified 
to further detail as you write.



Eyal Golan wrote:

Hi,
I have proposed to open a Wicket exam in JavaBlackBelt.
Here's my proposal:
http://www.javablackbelt.com/forum/posts/list/0/118.page#567

Please check it and give your thoughts.
I have already written several questions (to myself).

Thanks

  


--
-Wicket for love

Nino Martinez Wael
Java Specialist @ Jayway DK
http://www.jayway.dk
+45 2936 7684


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

Re: Java BlackBelt Wicket exam

Perhaps it could be for a yellow belt. ;)


On Fri, Sep 19, 2008 at 11:09 AM, Nino Saturnino Martinez Vazquez Wael
[EMAIL PROTECTED] wrote:
 Hi

 It looks fairly simple, I guess it depends on the depth of the exam...
 Because it could go over a lot more, or maybe the points could specified to
 further detail as you write.


 Eyal Golan wrote:

 Hi,
 I have proposed to open a Wicket exam in JavaBlackBelt.
 Here's my proposal:
 http://www.javablackbelt.com/forum/posts/list/0/118.page#567

 Please check it and give your thoughts.
 I have already written several questions (to myself).

 Thanks



 --
 -Wicket for love

 Nino Martinez Wael
 Java Specialist @ Jayway DK
 http://www.jayway.dk
 +45 2936 7684


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



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

Re: AW: Wicket and Mootools?

2008-09-19 Thread mahone9


I think I´m gonna use scriptaculous.
It´s much more easier to use it and I guess you can also compress the js
files as mootools does.
Scriptaculous provides almost that much effects as mootools.
JQuery is very poor on effects...



Nino.Martinez wrote:
 
 
 
 Agent Mahone wrote:
 O, thank u very much for ur comments.

 I have some questions to you:

 1. What is the package mini under contribution package for?
 What is the difference to package contribution/wicket-mootools???
   
 Im not sure how well managed wicket-mootools are...
 2. I also noticed that wicket offers you scriptaculous and jquery.
Is there any comparsion between that frameworks?
   
 Go google:)
 I´ve seen that scriptaculous is much more easier to understand and
 difinitely to use.

 Thanks again for any comments





 - Ursprüngliche Mail 
 Von: Nino Saturnino Martinez Vazquez Wael [EMAIL PROTECTED]
 An: users@wicket.apache.org
 Gesendet: Donnerstag, den 18. September 2008, 09:50:32 Uhr
 Betreff: Re: Wicket and Mootools?

 You can also check out the new addition to wicket stuff minis, the 
 mootips integration..

 Agent Mahone wrote:
   
 Hi all

 What is the best way to integrate mootools in wicket ?

 Does Mootools slow down the application? Does somebody had good
 expierence with it?

 Thanks in advane for any comments


 __
 Do You Yahoo!?
 Sie sind Spam leid? Yahoo! Mail verfügt über einen herausragenden Schutz
 gegen Massenmails. 
 http://mail.yahoo.com 
  
 

   
 
 -- 
 -Wicket for love
 
 Nino Martinez Wael
 Java Specialist @ Jayway DK
 http://www.jayway.dk
 +45 2936 7684
 
 
 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]
 
 
 

-- 
View this message in context: 
http://www.nabble.com/AW%3A-Wicket-and-Mootools--tp19550432p19574467.html
Sent from the Wicket - User mailing list archive at Nabble.com.


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

Re: Java BlackBelt Wicket exam

2008-09-19 Thread Eyal Golan

People,
it just a first draft.
As you saw in the first post, I just wanted to add questions for a Wicket
exam, and notified that there isn't.
Maybe it's possible to create a basic exam and a more advanced one?

I think we can all contribute.

On Fri, Sep 19, 2008 at 6:11 PM, James Carman [EMAIL PROTECTED]wrote:

 Perhaps it could be for a yellow belt. ;)


 On Fri, Sep 19, 2008 at 11:09 AM, Nino Saturnino Martinez Vazquez Wael
 [EMAIL PROTECTED] wrote:
  Hi
 
  It looks fairly simple, I guess it depends on the depth of the exam...
  Because it could go over a lot more, or maybe the points could specified
 to
  further detail as you write.
 
 
  Eyal Golan wrote:
 
  Hi,
  I have proposed to open a Wicket exam in JavaBlackBelt.
  Here's my proposal:
  http://www.javablackbelt.com/forum/posts/list/0/118.page#567
 
  Please check it and give your thoughts.
  I have already written several questions (to myself).
 
  Thanks
 
 
 
  --
  -Wicket for love
 
  Nino Martinez Wael
  Java Specialist @ Jayway DK
  http://www.jayway.dk
  +45 2936 7684
 
 
  -
  To unsubscribe, e-mail: [EMAIL PROTECTED]
  For additional commands, e-mail: [EMAIL PROTECTED]
 
 

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




-- 
Eyal Golan
[EMAIL PROTECTED]

Visit: http://jvdrums.sourceforge.net/
LinkedIn: http://www.linkedin.com/in/egolan74

P Save a tree. Please don't print this e-mail unless it's really necessary

Re: Java BlackBelt Wicket exam

I didn't mean to offend.  I was being facetious.  I think it's a great
idea to have different levels.

On Fri, Sep 19, 2008 at 11:29 AM, Eyal Golan [EMAIL PROTECTED] wrote:
 People,
 it just a first draft.
 As you saw in the first post, I just wanted to add questions for a Wicket
 exam, and notified that there isn't.
 Maybe it's possible to create a basic exam and a more advanced one?

 I think we can all contribute.

 On Fri, Sep 19, 2008 at 6:11 PM, James Carman [EMAIL PROTECTED]wrote:

 Perhaps it could be for a yellow belt. ;)


 On Fri, Sep 19, 2008 at 11:09 AM, Nino Saturnino Martinez Vazquez Wael
 [EMAIL PROTECTED] wrote:
  Hi
 
  It looks fairly simple, I guess it depends on the depth of the exam...
  Because it could go over a lot more, or maybe the points could specified
 to
  further detail as you write.
 
 
  Eyal Golan wrote:
 
  Hi,
  I have proposed to open a Wicket exam in JavaBlackBelt.
  Here's my proposal:
  http://www.javablackbelt.com/forum/posts/list/0/118.page#567
 
  Please check it and give your thoughts.
  I have already written several questions (to myself).
 
  Thanks
 
 
 
  --
  -Wicket for love
 
  Nino Martinez Wael
  Java Specialist @ Jayway DK
  http://www.jayway.dk
  +45 2936 7684
 
 
  -
  To unsubscribe, e-mail: [EMAIL PROTECTED]
  For additional commands, e-mail: [EMAIL PROTECTED]
 
 

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




 --
 Eyal Golan
 [EMAIL PROTECTED]

 Visit: http://jvdrums.sourceforge.net/
 LinkedIn: http://www.linkedin.com/in/egolan74

 P Save a tree. Please don't print this e-mail unless it's really necessary


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

Re: Markup for disabled Link - Proposal (add behavior instead of markup)

Of course, you are right. Sorry, what I wrote was not completely clear.
It can make sense to change the markup in order to disable a link.
It definitely makes sense to exchange [a] with [span], yes.

I was merely targeting at the appearance part: I think that adding markup
between this [span] element and its content is not very useful in most
cases. Of course, the functionality may come in handy if there is need, I
just think it should not necessarily be done by default.
And if there is a global setting for this, a global setting for a
defaultDisabledLinkBehavior would definitely be a good idea, too.

I would guess that most people are calling setDefaultAfterDisabledLink()
and setDefaultBeforeDisabledLink() to turn this behavior off, or use CSS
in order to have their text non-italic again, and add an AttributeModifier
instead. IMO it is just more obvious and more logical from the HTML template
and semantic point of view, even more when we are talking about [em].

However, if you do not share my opinion, I can stick to overriding the
default behavior, of course :)

igor.vaynberg wrote:

-igor

On Fri, Sep 19, 2008 at 4:21 AM, pixologe [EMAIL PROTECTED] wrote:

Dear Wicket devs,

I propose that by default a disabled link should rather (or also) be
marked
using a behavior, instead of adding markup before and after.

A word in advance: I know that I can implement my own version of Link
which
adds behavior in case of being disabled, and I know how to do it - this
is
not a cry for help, just a proposal, how I think the Link component
should
behave to fit most common use cases. The current way simple does not feel
right.

Why do I think so? When creating a template, most people tend to display
a
disabled status of an element by appending a css class to its tag, you
can
see class=disabled very often, making colors gray or applying
transparency.
IMHO something like this should not be done by changing the DOM hierarchy
of
the element.

Example: a Link with an arrow image (CSS background) - quite common. It
is
not (at least as easy as it should be) possible to have another image for
a
disabled link with this behavior, since there is nothing like an
if-element-has-child-element-selector in CSS.

Besides (I know it is configurable, but...) : I am not sure why one would
want to [em]phasize something that's disabled ;-)

I would love to see a defaultDisabledLinkBehavior property in future
versions, this would make it a lot easier to style disabled links...

Cheers + best regards :)

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

--
View this message in context:
http://www.nabble.com/Markup-for-disabled-Link---Proposal-%28add-behavior-instead-of-markup%29-tp19570584p19575441.html
Sent from the Wicket - User mailing list archive at Nabble.com.

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

Re: Java BlackBelt Wicket exam

2008-09-19 Thread Nino Saturnino Martinez Vazquez Wael


Yeah.. It's good:)

What about covering the stuff WIA drags you through, that should be good 
enough for a brown belt:)



James Carman wrote:

I didn't mean to offend.  I was being facetious.  I think it's a great
idea to have different levels.

On Fri, Sep 19, 2008 at 11:29 AM, Eyal Golan [EMAIL PROTECTED] wrote:
  

People,
it just a first draft.
As you saw in the first post, I just wanted to add questions for a Wicket
exam, and notified that there isn't.
Maybe it's possible to create a basic exam and a more advanced one?

I think we can all contribute.

On Fri, Sep 19, 2008 at 6:11 PM, James Carman [EMAIL PROTECTED]wrote:



Perhaps it could be for a yellow belt. ;)


On Fri, Sep 19, 2008 at 11:09 AM, Nino Saturnino Martinez Vazquez Wael
[EMAIL PROTECTED] wrote:
  

Hi

It looks fairly simple, I guess it depends on the depth of the exam...
Because it could go over a lot more, or maybe the points could specified


to
  

further detail as you write.


Eyal Golan wrote:


Hi,
I have proposed to open a Wicket exam in JavaBlackBelt.
Here's my proposal:
http://www.javablackbelt.com/forum/posts/list/0/118.page#567

Please check it and give your thoughts.
I have already written several questions (to myself).

Thanks


  

--
-Wicket for love

Nino Martinez Wael
Java Specialist @ Jayway DK
http://www.jayway.dk
+45 2936 7684


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




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


  

--
Eyal Golan
[EMAIL PROTECTED]

Visit: http://jvdrums.sourceforge.net/
LinkedIn: http://www.linkedin.com/in/egolan74

P Save a tree. Please don't print this e-mail unless it's really necessary




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

  


--
-Wicket for love

Nino Martinez Wael
Java Specialist @ Jayway DK
http://www.jayway.dk
+45 2936 7684


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

Re: Markup for disabled Link - Proposal (add behavior instead of markup)

On Fri, Sep 19, 2008 at 9:24 AM, pixologe [EMAIL PROTECTED] wrote:

Of course, you are right. Sorry, what I wrote was not completely clear.
It can make sense to change the markup in order to disable a link.
It definitely makes sense to exchange [a] with [span], yes.

there is a global setting

-igor

However, if you do not share my opinion, I can stick to overriding the
default behavior, of course :)

igor.vaynberg wrote:

-igor

On Fri, Sep 19, 2008 at 4:21 AM, pixologe [EMAIL PROTECTED] wrote:

Dear Wicket devs,

I propose that by default a disabled link should rather (or also) be
marked
using a behavior, instead of adding markup before and after.

A word in advance: I know that I can implement my own version of Link
which
adds behavior in case of being disabled, and I know how to do it - this
is
not a cry for help, just a proposal, how I think the Link component
should
behave to fit most common use cases. The current way simple does not feel
right.

Why do I think so? When creating a template, most people tend to display
a
disabled status of an element by appending a css class to its tag, you
can
see class=disabled very often, making colors gray or applying
transparency.
IMHO something like this should not be done by changing the DOM hierarchy
of
the element.

Example: a Link with an arrow image (CSS background) - quite common. It
is
not (at least as easy as it should be) possible to have another image for
a
disabled link with this behavior, since there is nothing like an
if-element-has-child-element-selector in CSS.

Besides (I know it is configurable, but...) : I am not sure why one would
want to [em]phasize something that's disabled ;-)

I would love to see a defaultDisabledLinkBehavior property in future
versions, this would make it a lot easier to style disabled links...

Cheers + best regards :)

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

CSS NOT FOUND

2008-09-19 Thread Murilo Aguiar

What is wrong with my CSS???

*TemplatePage.java

public TemplatePage(){
add(HeaderContributor.forCss(template.css));*

In the browser

*head
title wicket:id=titleSisWicket 0.1 testKiller/title
link rel=stylesheet type=text/css href=template.css /
/head

*File template.css is in the same package of file TemplatePage.java*
*

it is necessary plus some code?
I know that is simple but he is not functioning ...

thanks

-- 
---
Murilo Vieira Aguiar
Analista de Sistemas/Desenvolvedor JAVA
Tel. Comercial: [55] (63) 3218-1188 Secretaria do Planejamento/TO
Tel. Celular: [55] (63) 8404-4479
---

Re: CSS NOT FOUND

use forCss(TemplatePage.class, template.css)

-igor

On Fri, Sep 19, 2008 at 10:45 AM, Murilo Aguiar [EMAIL PROTECTED] wrote:
 What is wrong with my CSS???

 *TemplatePage.java

public TemplatePage(){
add(HeaderContributor.forCss(template.css));*

 In the browser

 *head
title wicket:id=titleSisWicket 0.1 testKiller/title
 link rel=stylesheet type=text/css href=template.css /
 /head

 *File template.css is in the same package of file TemplatePage.java*
 *

 it is necessary plus some code?
 I know that is simple but he is not functioning ...

 thanks

 --
 ---
 Murilo Vieira Aguiar
 Analista de Sistemas/Desenvolvedor JAVA
 Tel. Comercial: [55] (63) 3218-1188 Secretaria do Planejamento/TO
 Tel. Celular: [55] (63) 8404-4479
 ---


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

Re: Disabling RadioGroup via authorization strategy does not disable contained Radio buttons

create a jira issue for this

-igor

On Fri, Sep 19, 2008 at 7:11 AM, Joel Hill [EMAIL PROTECTED] wrote:
 I'm doing some component-based authorization and I'm trying to disable an 
 entire RadioGroup without having to tie the authorization to each individual 
 Radio button.  Were I to directly disable the RadioGroup, it looks like the 
 Radio buttons would also disable (but I haven't tested this); but it will not 
 disable all the choices when I tie an authorization strategy to the 
 RadioGroup.

 I'm working with wicket 1.3.3, so has this problem been addressed in a later 
 versoin, and if not, is there some reason we might not want to do this?

 Thanks.

 Joel


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



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

Re: Wicket sample application

2008-09-19 Thread superoverdrive

But none with database access ?

 Original-Nachricht 
 Datum: Thu, 18 Sep 2008 05:05:21 -0700 (PDT)
 Von: Michael Sparer [EMAIL PROTECTED]
 An: users@wicket.apache.org
 Betreff: Re: Wicket sample application

 
 just go a click further and you'll find plenty
 http://www.wicketstuff.org/wicket13/
 http://www.wicketstuff.org/wicket13/ajax/
 http://wicketstuff.org/confluence/display/STUFFWIKI/wicket-contrib-examples
 http://wicketstuff.org/confluence/display/STUFFWIKI/wicket-phonebook
 
 
 superoverdrive wrote:
  
  Hi there!
  
  I am looking for a Wicket sample application (e.g. something like a
  Petshop) - ideally once that includes things such as: User
 registration,
  Admin area, editing data (e.g. with Ajax auto-complete) and an example
 of
  displaying data in a table that is read incrementally from the database
  (e.g. displaying huge database tables without crashing)
  
  On the Wicket homepage there are just small examples, but no complete
  websites done in Wicket
  
  Something like:
  
  http://bakery.cakephp.org/categories/view/3
  
  would be good for Wicket:
  
  Thanks!
  
  Toby
  
  -
  To unsubscribe, e-mail: [EMAIL PROTECTED]
  For additional commands, e-mail: [EMAIL PROTECTED]
  
  
  
 
 
 -
 Michael Sparer
 http://talk-on-tech.blogspot.com
 -- 
 View this message in context:
 http://www.nabble.com/Wicket-sample-application-tp19549890p19551321.html
 Sent from the Wicket - User mailing list archive at Nabble.com.
 
 
 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]

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

Re: Wicket sample application

see wicket-phonebook in wicket-stuff svn

-igor

On Fri, Sep 19, 2008 at 10:54 AM,  [EMAIL PROTECTED] wrote:
 But none with database access ?

  Original-Nachricht 
 Datum: Thu, 18 Sep 2008 05:05:21 -0700 (PDT)
 Von: Michael Sparer [EMAIL PROTECTED]
 An: users@wicket.apache.org
 Betreff: Re: Wicket sample application


 just go a click further and you'll find plenty
 http://www.wicketstuff.org/wicket13/
 http://www.wicketstuff.org/wicket13/ajax/
 http://wicketstuff.org/confluence/display/STUFFWIKI/wicket-contrib-examples
 http://wicketstuff.org/confluence/display/STUFFWIKI/wicket-phonebook


 superoverdrive wrote:
 
  Hi there!
 
  I am looking for a Wicket sample application (e.g. something like a
  Petshop) - ideally once that includes things such as: User
 registration,
  Admin area, editing data (e.g. with Ajax auto-complete) and an example
 of
  displaying data in a table that is read incrementally from the database
  (e.g. displaying huge database tables without crashing)
 
  On the Wicket homepage there are just small examples, but no complete
  websites done in Wicket
 
  Something like:
 
  http://bakery.cakephp.org/categories/view/3
 
  would be good for Wicket:
 
  Thanks!
 
  Toby
 
  -
  To unsubscribe, e-mail: [EMAIL PROTECTED]
  For additional commands, e-mail: [EMAIL PROTECTED]
 
 
 


 -
 Michael Sparer
 http://talk-on-tech.blogspot.com
 --
 View this message in context:
 http://www.nabble.com/Wicket-sample-application-tp19549890p19551321.html
 Sent from the Wicket - User mailing list archive at Nabble.com.


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

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



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

Re: Wicket sample application

2008-09-19 Thread Eelco Hillenius

Phonebook has db access. And one of the examples that come with Wicket
In Action has that too.

Eelco

On Fri, Sep 19, 2008 at 10:54 AM,  [EMAIL PROTECTED] wrote:
 But none with database access ?

  Original-Nachricht 
 Datum: Thu, 18 Sep 2008 05:05:21 -0700 (PDT)
 Von: Michael Sparer [EMAIL PROTECTED]
 An: users@wicket.apache.org
 Betreff: Re: Wicket sample application


 just go a click further and you'll find plenty
 http://www.wicketstuff.org/wicket13/
 http://www.wicketstuff.org/wicket13/ajax/
 http://wicketstuff.org/confluence/display/STUFFWIKI/wicket-contrib-examples
 http://wicketstuff.org/confluence/display/STUFFWIKI/wicket-phonebook


 superoverdrive wrote:
 
  Hi there!
 
  I am looking for a Wicket sample application (e.g. something like a
  Petshop) - ideally once that includes things such as: User
 registration,
  Admin area, editing data (e.g. with Ajax auto-complete) and an example
 of
  displaying data in a table that is read incrementally from the database
  (e.g. displaying huge database tables without crashing)
 
  On the Wicket homepage there are just small examples, but no complete
  websites done in Wicket
 
  Something like:
 
  http://bakery.cakephp.org/categories/view/3
 
  would be good for Wicket:
 
  Thanks!
 
  Toby
 
  -
  To unsubscribe, e-mail: [EMAIL PROTECTED]
  For additional commands, e-mail: [EMAIL PROTECTED]
 
 
 


 -
 Michael Sparer
 http://talk-on-tech.blogspot.com
 --
 View this message in context:
 http://www.nabble.com/Wicket-sample-application-tp19549890p19551321.html
 Sent from the Wicket - User mailing list archive at Nabble.com.


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

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



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

Re: CSS NOT FOUND

2008-09-19 Thread Murilo Aguiar

thanks a lot ... very simple

Murilo Aguiar

2008/9/19 Igor Vaynberg [EMAIL PROTECTED]

 use forCss(TemplatePage.class, template.css)

 -igor

 On Fri, Sep 19, 2008 at 10:45 AM, Murilo Aguiar [EMAIL PROTECTED]
 wrote:
  What is wrong with my CSS???
 
  *TemplatePage.java
 
 public TemplatePage(){
 add(HeaderContributor.forCss(template.css));*
 
  In the browser
 
  *head
 title wicket:id=titleSisWicket 0.1 testKiller/title
  link rel=stylesheet type=text/css href=template.css /
  /head
 
  *File template.css is in the same package of file TemplatePage.java*
  *
 
  it is necessary plus some code?
  I know that is simple but he is not functioning ...
 
  thanks
 
  --
 
 ---
  Murilo Vieira Aguiar
  Analista de Sistemas/Desenvolvedor JAVA
  Tel. Comercial: [55] (63) 3218-1188 Secretaria do Planejamento/TO
  Tel. Celular: [55] (63) 8404-4479
 
 ---
 

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




-- 
---
Murilo Vieira Aguiar
Analista de Sistemas/Desenvolvedor JAVA
Tel. Comercial: [55] (63) 3218-1188 Secretaria do Planejamento/TO
Tel. Celular: [55] (63) 8404-4479
---

Re: Markup for disabled Link - Proposal (add behavior instead of markup)

would you mind giving a hint?

igor.vaynberg wrote:

On Fri, Sep 19, 2008 at 9:24 AM, pixologe [EMAIL PROTECTED] wrote:

Of course, you are right. Sorry, what I wrote was not completely clear.
It can make sense to change the markup in order to disable a link.
It definitely makes sense to exchange [a] with [span], yes.

there is a global setting

-igor

I would guess that most people are calling
setDefaultAfterDisabledLink()
and setDefaultBeforeDisabledLink() to turn this behavior off, or use
CSS
in order to have their text non-italic again, and add an
AttributeModifier
instead. IMO it is just more obvious and more logical from the HTML
template
and semantic point of view, even more when we are talking about [em].

However, if you do not share my opinion, I can stick to overriding the
default behavior, of course :)

igor.vaynberg wrote:

-igor

On Fri, Sep 19, 2008 at 4:21 AM, pixologe [EMAIL PROTECTED]
wrote:

Dear Wicket devs,

I propose that by default a disabled link should rather (or also) be
marked
using a behavior, instead of adding markup before and after.

A word in advance: I know that I can implement my own version of Link
which
adds behavior in case of being disabled, and I know how to do it - this
is
not a cry for help, just a proposal, how I think the Link component
should
behave to fit most common use cases. The current way simple does not
feel
right.

Why do I think so? When creating a template, most people tend to
display
a
disabled status of an element by appending a css class to its tag, you
can
see class=disabled very often, making colors gray or applying
transparency.
IMHO something like this should not be done by changing the DOM
hierarchy
of
the element.

Example: a Link with an arrow image (CSS background) - quite common. It
is
not (at least as easy as it should be) possible to have another image
for
a
disabled link with this behavior, since there is nothing like an
if-element-has-child-element-selector in CSS.

Besides (I know it is configurable, but...) : I am not sure why one
would
want to [em]phasize something that's disabled ;-)

I would love to see a defaultDisabledLinkBehavior property in future
versions, this would make it a lot easier to style disabled links...

Cheers + best regards :)

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

--
View this message in context:
http://www.nabble.com/Markup-for-disabled-Link---Proposal-%28add-behavior-instead-of-markup%29-tp19570584p19577220.html
Sent from the Wicket - User mailing list archive at Nabble.com.

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

Re: Markup for disabled Link - Proposal (add behavior instead of markup)

application.getmarkupsettings()

-igor

On Fri, Sep 19, 2008 at 11:15 AM, pixologe [EMAIL PROTECTED] wrote:

would you mind giving a hint?

igor.vaynberg wrote:

On Fri, Sep 19, 2008 at 9:24 AM, pixologe [EMAIL PROTECTED] wrote:

Of course, you are right. Sorry, what I wrote was not completely clear.
It can make sense to change the markup in order to disable a link.
It definitely makes sense to exchange [a] with [span], yes.

there is a global setting

-igor

I would guess that most people are calling
setDefaultAfterDisabledLink()
and setDefaultBeforeDisabledLink() to turn this behavior off, or use
CSS
in order to have their text non-italic again, and add an
AttributeModifier
instead. IMO it is just more obvious and more logical from the HTML
template
and semantic point of view, even more when we are talking about [em].

However, if you do not share my opinion, I can stick to overriding the
default behavior, of course :)

igor.vaynberg wrote:

-igor

On Fri, Sep 19, 2008 at 4:21 AM, pixologe [EMAIL PROTECTED]
wrote:

Dear Wicket devs,

I propose that by default a disabled link should rather (or also) be
marked
using a behavior, instead of adding markup before and after.

A word in advance: I know that I can implement my own version of Link
which
adds behavior in case of being disabled, and I know how to do it - this
is
not a cry for help, just a proposal, how I think the Link component
should
behave to fit most common use cases. The current way simple does not
feel
right.

Why do I think so? When creating a template, most people tend to
display
a
disabled status of an element by appending a css class to its tag, you
can
see class=disabled very often, making colors gray or applying
transparency.
IMHO something like this should not be done by changing the DOM
hierarchy
of
the element.

Example: a Link with an arrow image (CSS background) - quite common. It
is
not (at least as easy as it should be) possible to have another image
for
a
disabled link with this behavior, since there is nothing like an
if-element-has-child-element-selector in CSS.

Besides (I know it is configurable, but...) : I am not sure why one
would
want to [em]phasize something that's disabled ;-)

I would love to see a defaultDisabledLinkBehavior property in future
versions, this would make it a lot easier to style disabled links...

Cheers + best regards :)

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

Re: Markup for disabled Link - Proposal (add behavior instead of markup)

setDefault*DisabledLink?
I know them and I am using them, as I already wrote.

Just considered it would be nice to have setDefaultDisabledLinkBehavior,
too. And that I think it would be more obvious to have this applied by
default.

Was just a proposal, never mind.

igor.vaynberg wrote:

application.getmarkupsettings()

-igor

On Fri, Sep 19, 2008 at 11:15 AM, pixologe [EMAIL PROTECTED]
wrote:

would you mind giving a hint?

igor.vaynberg wrote:

On Fri, Sep 19, 2008 at 9:24 AM, pixologe [EMAIL PROTECTED]
wrote:

Of course, you are right. Sorry, what I wrote was not completely clear.
It can make sense to change the markup in order to disable a link.
It definitely makes sense to exchange [a] with [span], yes.

I was merely targeting at the appearance part: I think that adding
markup
between this [span] element and its content is not very useful in most
cases. Of course, the functionality may come in handy if there is need,
I
just think it should not necessarily be done by default.
And if there is a global setting for this, a global setting for a
defaultDisabledLinkBehavior would definitely be a good idea, too.

there is a global setting

-igor

I would guess that most people are calling
setDefaultAfterDisabledLink()
and setDefaultBeforeDisabledLink() to turn this behavior off, or use
CSS
in order to have their text non-italic again, and add an
AttributeModifier
instead. IMO it is just more obvious and more logical from the HTML
template
and semantic point of view, even more when we are talking about [em].

However, if you do not share my opinion, I can stick to overriding the
default behavior, of course :)

igor.vaynberg wrote:

-igor

On Fri, Sep 19, 2008 at 4:21 AM, pixologe [EMAIL PROTECTED]
wrote:

Dear Wicket devs,

I propose that by default a disabled link should rather (or also) be
marked
using a behavior, instead of adding markup before and after.

A word in advance: I know that I can implement my own version of Link
which
adds behavior in case of being disabled, and I know how to do it -
this
is
not a cry for help, just a proposal, how I think the Link component
should
behave to fit most common use cases. The current way simple does not
feel
right.

Why do I think so? When creating a template, most people tend to
display
a
disabled status of an element by appending a css class to its tag,
you
can
see class=disabled very often, making colors gray or applying
transparency.
IMHO something like this should not be done by changing the DOM
hierarchy
of
the element.

Example: a Link with an arrow image (CSS background) - quite common.
It
is
not (at least as easy as it should be) possible to have another image
for
a
disabled link with this behavior, since there is nothing like an
if-element-has-child-element-selector in CSS.

Besides (I know it is configurable, but...) : I am not sure why one
would
want to [em]phasize something that's disabled ;-)

I would love to see a defaultDisabledLinkBehavior property in future
versions, this would make it a lot easier to style disabled links...

Cheers + best regards :)

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

Re: Transactions..... again!

2008-09-19 Thread Erik van Oosten


Ryan,

Here is how I do this with Spring: 
http://day-to-day-stuff.blogspot.com/2008/08/java-transaction-boundary-tricks.html

Its not as pretty as Salve's @Transactional but just as effective.

Regards,
Erik.


Ryan wrote:

Aside from these ideas, has anyone used a different method for starting
transactions inside of wicket when needed?

  



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

Re: Wicket sample application

2008-09-19 Thread Gwyn Evans

http://cwiki.apache.org/WICKET/documentation-index.html#DocumentationIndex-Codeasdocumentation

On Fri, Sep 19, 2008 at 7:00 PM, Eelco Hillenius
[EMAIL PROTECTED] wrote:
 Phonebook has db access. And one of the examples that come with Wicket
 In Action has that too.

 Eelco

 On Fri, Sep 19, 2008 at 10:54 AM,  [EMAIL PROTECTED] wrote:
 But none with database access ?

  Original-Nachricht 
 Datum: Thu, 18 Sep 2008 05:05:21 -0700 (PDT)
 Von: Michael Sparer [EMAIL PROTECTED]
 An: users@wicket.apache.org
 Betreff: Re: Wicket sample application


 just go a click further and you'll find plenty
 http://www.wicketstuff.org/wicket13/
 http://www.wicketstuff.org/wicket13/ajax/
 http://wicketstuff.org/confluence/display/STUFFWIKI/wicket-contrib-examples
 http://wicketstuff.org/confluence/display/STUFFWIKI/wicket-phonebook


 superoverdrive wrote:
 
  Hi there!
 
  I am looking for a Wicket sample application (e.g. something like a
  Petshop) - ideally once that includes things such as: User
 registration,
  Admin area, editing data (e.g. with Ajax auto-complete) and an example
 of
  displaying data in a table that is read incrementally from the database
  (e.g. displaying huge database tables without crashing)
 
  On the Wicket homepage there are just small examples, but no complete
  websites done in Wicket
 
  Something like:
 
  http://bakery.cakephp.org/categories/view/3
 
  would be good for Wicket:
 
  Thanks!
 
  Toby
 
  -
  To unsubscribe, e-mail: [EMAIL PROTECTED]
  For additional commands, e-mail: [EMAIL PROTECTED]
 
 
 


 -
 Michael Sparer
 http://talk-on-tech.blogspot.com
 --
 View this message in context:
 http://www.nabble.com/Wicket-sample-application-tp19549890p19551321.html
 Sent from the Wicket - User mailing list archive at Nabble.com.


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

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



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



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

Re: Markup for disabled Link - Proposal (add behavior instead of markup)

Thanks for inspiration, igor. :)
Well, it would not help the mentioned problem of not being able to change
the style of an element depending on its child elements. However, as I
thought about this, I realized that I could do some global changes in the
weird templates and stylesheets I got, so CSS could differentiate by
a.myClass and span.myClass. As these changes would cause a lot of
side-effects in the files, I think I'll better stick with the
AttributeAppender I've currently got in there.

Still I think that having markup in Java strings as well as using [em] to
mark disabledness are not the best ideas - but let's not discuss this any
longer :)

Cheers.

Example: a Link with an arrow image (CSS background) - quite common. It is
not (at least as easy as it should be) possible to have another image for
a disabled link with this behavior, since there is nothing like an
if-element-has-child-element-selector in CSS.

igor.vaynberg wrote:

setdefaultbeforedisabledlink( ) will do what you want

-igor

On Fri, Sep 19, 2008 at 11:27 AM, pixologe [EMAIL PROTECTED]
wrote:

setDefault*DisabledLink?
I know them and I am using them, as I already wrote.

Just considered it would be nice to have setDefaultDisabledLinkBehavior,
too. And that I think it would be more obvious to have this applied by
default.

Was just a proposal, never mind.

igor.vaynberg wrote:

application.getmarkupsettings()

-igor

On Fri, Sep 19, 2008 at 11:15 AM, pixologe [EMAIL PROTECTED]
wrote:

would you mind giving a hint?

igor.vaynberg wrote:

On Fri, Sep 19, 2008 at 9:24 AM, pixologe [EMAIL PROTECTED]
wrote:

Of course, you are right. Sorry, what I wrote was not completely
clear.
It can make sense to change the markup in order to disable a link.
It definitely makes sense to exchange [a] with [span], yes.

I was merely targeting at the appearance part: I think that adding
markup
between this [span] element and its content is not very useful in
most
cases. Of course, the functionality may come in handy if there is
need,
I
just think it should not necessarily be done by default.
And if there is a global setting for this, a global setting for a
defaultDisabledLinkBehavior would definitely be a good idea, too.

there is a global setting

-igor

I would guess that most people are calling
setDefaultAfterDisabledLink()
and setDefaultBeforeDisabledLink() to turn this behavior off, or
use
CSS
in order to have their text non-italic again, and add an
AttributeModifier
instead. IMO it is just more obvious and more logical from the HTML
template
and semantic point of view, even more when we are talking about [em].

However, if you do not share my opinion, I can stick to overriding
the
default behavior, of course :)

igor.vaynberg wrote:

disabled is more then just about the appearance, if something is
disabled the user should not be able to interact with it. for
example,
security strategy can disable links the user does not have access
to.
just adding class=disabled leaves the link clickable.

-igor

On Fri, Sep 19, 2008 at 4:21 AM, pixologe [EMAIL PROTECTED]
wrote:

Dear Wicket devs,

I propose that by default a disabled link should rather (or also)
be
marked
using a behavior, instead of adding markup before and after.

A word in advance: I know that I can implement my own version of
Link
which
adds behavior in case of being disabled, and I know how to do it -
this
is
not a cry for help, just a proposal, how I think the Link component
should
behave to fit most common use cases. The current way simple does
not
feel
right.

Why do I think so? When creating a template, most people tend to
display
a
disabled status of an element by appending a css class to its tag,
you
can
see class=disabled very often, making colors gray or applying
transparency.
IMHO something like this should not be done by changing the DOM
hierarchy
of
the element.

Example: a Link with an arrow image (CSS background) - quite
common.
It
is
not (at least as easy as it should be) possible to have another
image
for
a
disabled link with this behavior, since there is nothing like an
if-element-has-child-element-selector in CSS.

Besides (I know it is configurable, but...) : I am not sure why one
would
want to [em]phasize something that's disabled ;-)

I would love to see a defaultDisabledLinkBehavior property in
future
versions, this would make it a lot easier to style disabled
links...

Cheers + best regards :)

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

Kill session on closing browser


Does anyone know how a browser would find a pre-existing session after being
closed and reopened? I got a call from a user today who is able to stay
logged in, even after she closes her browser.

I had thought that closing a browser essentially destroys that user's
session (at least from the client's perspective.) I've tested this
elsewhere, and it sends me back to the login screen when I reopen the
browser, the way it's supposed to.

I appreciate any suggestions you've got. I've checked that she isn't using a
URL with a sessionid included. I'm using SWARM for authentication on the
site. Thanks!
-- 
View this message in context: 
http://www.nabble.com/Kill-session-on-closing-browser-tp19578217p19578217.html
Sent from the Wicket - User mailing list archive at Nabble.com.


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

Re: Kill session on closing browser

Are they closing all instances of the browser?

On Fri, Sep 19, 2008 at 3:30 PM, insom [EMAIL PROTECTED] wrote:

 Does anyone know how a browser would find a pre-existing session after being
 closed and reopened? I got a call from a user today who is able to stay
 logged in, even after she closes her browser.

 I had thought that closing a browser essentially destroys that user's
 session (at least from the client's perspective.) I've tested this
 elsewhere, and it sends me back to the login screen when I reopen the
 browser, the way it's supposed to.

 I appreciate any suggestions you've got. I've checked that she isn't using a
 URL with a sessionid included. I'm using SWARM for authentication on the
 site. Thanks!
 --
 View this message in context: 
 http://www.nabble.com/Kill-session-on-closing-browser-tp19578217p19578217.html
 Sent from the Wicket - User mailing list archive at Nabble.com.


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



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

Re: Kill session on closing browser

2008-09-19 Thread Matej Knopp

Either the browser doesn't kill cookie on close or she has cookies disabled,
had url with session id encoded and returned back to that url while the
session was still active server side.

-Matej

On Fri, Sep 19, 2008 at 9:34 PM, James Carman [EMAIL PROTECTED]wrote:

 Are they closing all instances of the browser?

 On Fri, Sep 19, 2008 at 3:30 PM, insom [EMAIL PROTECTED] wrote:
 
  Does anyone know how a browser would find a pre-existing session after
 being
  closed and reopened? I got a call from a user today who is able to stay
  logged in, even after she closes her browser.
 
  I had thought that closing a browser essentially destroys that user's
  session (at least from the client's perspective.) I've tested this
  elsewhere, and it sends me back to the login screen when I reopen the
  browser, the way it's supposed to.
 
  I appreciate any suggestions you've got. I've checked that she isn't
 using a
  URL with a sessionid included. I'm using SWARM for authentication on the
  site. Thanks!
  --
  View this message in context:
 http://www.nabble.com/Kill-session-on-closing-browser-tp19578217p19578217.html
  Sent from the Wicket - User mailing list archive at Nabble.com.
 
 
  -
  To unsubscribe, e-mail: [EMAIL PROTECTED]
  For additional commands, e-mail: [EMAIL PROTECTED]
 
 

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

Re: Wicket sample application

2008-09-19 Thread Nino Saturnino Martinez Vazquez Wael

Theres even the blog tutorial thing I did once aswell, although 
discontinued (as I thought no one used it)...


http://cwiki.apache.org/WICKET/blog-tutorial.html

Gwyn Evans wrote:

http://cwiki.apache.org/WICKET/documentation-index.html#DocumentationIndex-Codeasdocumentation

On Fri, Sep 19, 2008 at 7:00 PM, Eelco Hillenius
[EMAIL PROTECTED] wrote:
  

Phonebook has db access. And one of the examples that come with Wicket
In Action has that too.

Eelco

On Fri, Sep 19, 2008 at 10:54 AM,  [EMAIL PROTECTED] wrote:


But none with database access ?

 Original-Nachricht 
  

Datum: Thu, 18 Sep 2008 05:05:21 -0700 (PDT)
Von: Michael Sparer [EMAIL PROTECTED]
An: users@wicket.apache.org
Betreff: Re: Wicket sample application

just go a click further and you'll find plenty

http://www.wicketstuff.org/wicket13/
http://www.wicketstuff.org/wicket13/ajax/
http://wicketstuff.org/confluence/display/STUFFWIKI/wicket-contrib-examples
http://wicketstuff.org/confluence/display/STUFFWIKI/wicket-phonebook


superoverdrive wrote:


Hi there!

I am looking for a Wicket sample application (e.g. something like a
Petshop) - ideally once that includes things such as: User
  

registration,


Admin area, editing data (e.g. with Ajax auto-complete) and an example
  

of


displaying data in a table that is read incrementally from the database
(e.g. displaying huge database tables without crashing)

On the Wicket homepage there are just small examples, but no complete
websites done in Wicket

Something like:

http://bakery.cakephp.org/categories/view/3

would be good for Wicket:

Thanks!

Toby

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



  

-
Michael Sparer
http://talk-on-tech.blogspot.com
--
View this message in context:
http://www.nabble.com/Wicket-sample-application-tp19549890p19551321.html
Sent from the Wicket - User mailing list archive at Nabble.com.


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


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


  

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





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

  


--
-Wicket for love

Nino Martinez Wael
Java Specialist @ Jayway DK
http://www.jayway.dk
+45 2936 7684


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

Re: Kill session on closing browser


It turns out she did have another browser window open. I witnessed the issue
on her machine, but I haven't been able to replicate it on my own. I've
tried visiting the website, logging in, opening another browser window, then
closing either the new or the old window (I've tried both ways), reopening
the browser, and going back to the site -- but it always sends me back to
the login page (which is what I want the site to do, but I'm concerned about
issues that I can't replicate.)

If anyone cares to check it out (and feel under no obligation to -- it's not
a big issue for anyone except me, who wants to figure this out) you can
visit the site at www.foodhandler.org and login with username
[EMAIL PROTECTED] password guest.

Thanks again for your responses -- you're wonderful people!


Matej Knopp-2 wrote:
 
 Either the browser doesn't kill cookie on close or she has cookies
 disabled,
 had url with session id encoded and returned back to that url while the
 session was still active server side.
 
 -Matej
 
 On Fri, Sep 19, 2008 at 9:34 PM, James Carman
 [EMAIL PROTECTED]wrote:
 
 Are they closing all instances of the browser?

 On Fri, Sep 19, 2008 at 3:30 PM, insom [EMAIL PROTECTED] wrote:
 
  Does anyone know how a browser would find a pre-existing session after
 being
  closed and reopened? I got a call from a user today who is able to stay
  logged in, even after she closes her browser.
 
  I had thought that closing a browser essentially destroys that user's
  session (at least from the client's perspective.) I've tested this
  elsewhere, and it sends me back to the login screen when I reopen the
  browser, the way it's supposed to.
 
  I appreciate any suggestions you've got. I've checked that she isn't
 using a
  URL with a sessionid included. I'm using SWARM for authentication on
 the
  site. Thanks!
  --
  View this message in context:
 http://www.nabble.com/Kill-session-on-closing-browser-tp19578217p19578217.html
  Sent from the Wicket - User mailing list archive at Nabble.com.
 
 
  -
  To unsubscribe, e-mail: [EMAIL PROTECTED]
  For additional commands, e-mail: [EMAIL PROTECTED]
 
 

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


 
 

-- 
View this message in context: 
http://www.nabble.com/Kill-session-on-closing-browser-tp19578217p19579928.html
Sent from the Wicket - User mailing list archive at Nabble.com.


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

Re: Kill session on closing browser


I figured it out. If you login to the site, then open another window and
visit to the site you will have to login again. But if you login to the
site, then open a shortcut in a new window that goes directly to
http://www.foodhandler.org, you will be already logged in.

I have no idea why opening a blank browser window and navigating to the site
is any different from opening a shortcut to the site directly -- I would
have thought that each would request in the same way, but apparently that's
not the case.


insom wrote:
 
 It turns out she did have another browser window open. I witnessed the
 issue on her machine, but I haven't been able to replicate it on my own.
 I've tried visiting the website, logging in, opening another browser
 window, then closing either the new or the old window (I've tried both
 ways), reopening the browser, and going back to the site -- but it always
 sends me back to the login page (which is what I want the site to do, but
 I'm concerned about issues that I can't replicate.)
 
 If anyone cares to check it out (and feel under no obligation to -- it's
 not a big issue for anyone except me, who wants to figure this out) you
 can visit the site at www.foodhandler.org and login with username
 [EMAIL PROTECTED] password guest.
 
 Thanks again for your responses -- you're wonderful people!
 

-- 
View this message in context: 
http://www.nabble.com/Kill-session-on-closing-browser-tp19578217p19580513.html
Sent from the Wicket - User mailing list archive at Nabble.com.


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

Re: Kill session on closing browser

2008-09-19 Thread Maarten Bosteels

On Sat, Sep 20, 2008 at 12:45 AM, insom [EMAIL PROTECTED] wrote:

 I figured it out. If you login to the site, then open another window and
 visit to the site you will have to login again. But if you login to the
 site, then open a shortcut in a new window that goes directly to
 http://www.foodhandler.org, you will be already logged in.

That's not what I see:  when I am logged in (with guest account) in
one browser tab, I don't have to in again in other tabs or other
browser windows, no matter how I open them.
Which is what I expect: the browser (firefox) is sending the
JSESSIONID cookie for every request to the site.
As soon as I log out in one tab, I am logged out in all tabs and windows.

HTH,
Maarten



 I have no idea why opening a blank browser window and navigating to the site
 is any different from opening a shortcut to the site directly -- I would
 have thought that each would request in the same way, but apparently that's
 not the case.


 insom wrote:

 It turns out she did have another browser window open. I witnessed the
 issue on her machine, but I haven't been able to replicate it on my own.
 I've tried visiting the website, logging in, opening another browser
 window, then closing either the new or the old window (I've tried both
 ways), reopening the browser, and going back to the site -- but it always
 sends me back to the login page (which is what I want the site to do, but
 I'm concerned about issues that I can't replicate.)

 If anyone cares to check it out (and feel under no obligation to -- it's
 not a big issue for anyone except me, who wants to figure this out) you
 can visit the site at www.foodhandler.org and login with username
 [EMAIL PROTECTED] password guest.

 Thanks again for your responses -- you're wonderful people!


 --
 View this message in context: 
 http://www.nabble.com/Kill-session-on-closing-browser-tp19578217p19580513.html
 Sent from the Wicket - User mailing list archive at Nabble.com.


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



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

Re: Kill session on closing browser