from:"Igor Vaynberg"


 [ 
https://issues.apache.org/jira/browse/WICKET-5462?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Igor Vaynberg updated WICKET-5462:
--

Summary: Ajax form-component-label repainting fails when setResponsePage() 
is used to navigate away from the page that has previously failed form 
validaiton  (was: Automatic form-component-label repainting fails when 
setResponsePage() is used to navigate away from the page that has previously 
failed form validaiton)

 Ajax form-component-label repainting fails when setResponsePage() is used to 
 navigate away from the page that has previously failed form validaiton
 ---

 Key: WICKET-5462
 URL: https://issues.apache.org/jira/browse/WICKET-5462
 Project: Wicket
  Issue Type: Bug
Reporter: Igor Vaynberg
Assignee: Igor Vaynberg





--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Created] (WICKET-5462) Automatic form-component-label repainting fails when setResponsePage() is used to navigate away from the page that has previously failed form validaiton

Igor Vaynberg created WICKET-5462:
-

 Summary: Automatic form-component-label repainting fails when 
setResponsePage() is used to navigate away from the page that has previously 
failed form validaiton
 Key: WICKET-5462
 URL: https://issues.apache.org/jira/browse/WICKET-5462
 Project: Wicket
  Issue Type: Bug
Reporter: Igor Vaynberg
Assignee: Igor Vaynberg






--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Resolved] (WICKET-5462) Ajax form-component-label repainting fails when setResponsePage() is used to navigate away from the page that has previously failed form validaiton


 [ 
https://issues.apache.org/jira/browse/WICKET-5462?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Igor Vaynberg resolved WICKET-5462.
---

   Resolution: Fixed
Fix Version/s: 7.0.0
   6.13.0

 Ajax form-component-label repainting fails when setResponsePage() is used to 
 navigate away from the page that has previously failed form validaiton
 ---

 Key: WICKET-5462
 URL: https://issues.apache.org/jira/browse/WICKET-5462
 Project: Wicket
  Issue Type: Bug
Reporter: Igor Vaynberg
Assignee: Igor Vaynberg
 Fix For: 6.13.0, 7.0.0






--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Updated] (WICKET-5462) Ajax form-component-label repainting fails when setResponsePage() is used to navigate away from the page that has previously failed form validaiton


 [ 
https://issues.apache.org/jira/browse/WICKET-5462?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Igor Vaynberg updated WICKET-5462:
--

Fix Version/s: (was: 6.13.0)
   6.14.0

 Ajax form-component-label repainting fails when setResponsePage() is used to 
 navigate away from the page that has previously failed form validaiton
 ---

 Key: WICKET-5462
 URL: https://issues.apache.org/jira/browse/WICKET-5462
 Project: Wicket
  Issue Type: Bug
Reporter: Igor Vaynberg
Assignee: Igor Vaynberg
 Fix For: 6.14.0, 7.0.0






--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

Re: [jira] [Resolved] (WICKET-5462) Ajax form-component-label repainting fails when setResponsePage() is used to navigate away from the page that has previously failed form validaiton

2014-01-06 Thread Igor Vaynberg

indeed, 6.13 hasnt been marked as released in jira yet...

On Mon, Jan 6, 2014 at 11:47 AM, Sven Meier s...@meiers.net wrote:
  Fix Version/s: 7.0.0
 6.13.0


 That should be 6.14.0, no?

 Sven



 On 01/06/2014 07:27 PM, Igor Vaynberg (JIRA) wrote:

   [
 https://issues.apache.org/jira/browse/WICKET-5462?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

 Igor Vaynberg resolved WICKET-5462.
 ---

 Resolution: Fixed
  Fix Version/s: 7.0.0
 6.13.0

 Ajax form-component-label repainting fails when setResponsePage() is used
 to navigate away from the page that has previously failed form validaiton

 ---

  Key: WICKET-5462
  URL: https://issues.apache.org/jira/browse/WICKET-5462
  Project: Wicket
   Issue Type: Bug
 Reporter: Igor Vaynberg
 Assignee: Igor Vaynberg
  Fix For: 6.13.0, 7.0.0





 --
 This message was sent by Atlassian JIRA
 (v6.1.5#6160)

Re: The state of Wicket 6.13

2014-01-05 Thread Igor Vaynberg

+1 to rebase

On Sun, Jan 5, 2014 at 8:39 AM, Martijn Dashorst
martijn.dasho...@gmail.com wrote:
 All,

 Since a long time I have tried to coerce the Maven release plugin to
 actually build a release. It appears that newer versions of git have
 altered the output format on which the m-r-p depends to commit the pom
 changes (release poms) and then tag that result. This caused a bug
 hunt and trial/error period of weeks to finally just now when I was
 able to build a 6.13.0 release.

 Now this is the state of 4 weeks ago, and I wonder if it is more
 proper to rebase to now and cut a release from that. Personally I
 would do just that (rebase to now and release that). Opinions?

 Martijn

 --
 Become a Wicket expert, learn from the best: http://wicketinaction.com

Re: Passing Component or Class to IAuthorizationStrategy#isInstantiationAuthorized()

2013-12-20 Thread Igor Vaynberg

this is a security check, so the whole idea is that it is ran before
any of the user's code in the constructor which may have side-effects.
eg a constructor marking a record as ready to be deleted because a
delete panel was instantiated. the class itself should be enough. even
if you get an instance you cant use anything in it because its
partially constructed. the question is if we do pass an instance how
many users will bother reading javadoc? and out of those how many
really understand how objects are constructed? i think we should close
the issue as wont-fix, reading it It would be easier to decide if
instantiation is authorized if one could access some properties of the
component being constructed. which is exactly what you cannot/must
not do because the object is only partially initialized, thus proving
my point above.

the ComponentInstantiationListener is a very special case where we
make an exception. the entire point of this interface is to work with
a partially constructed object and most users will never implement
their own as opposed to the authorization strategy...

-igor

On Fri, Dec 20, 2013 at 12:53 AM, Martin Grigorov mgrigo...@apache.org wrote:
Hi,

The reporter of https://issues.apache.org/jira/browse/WICKET-5454 asked to
pass the Component instance
to IAuthorizationStrategy#isInstantiationAuthorized() instead of just its
class.
I have no idea why the API has been designed this way but Carl-Eric gave a
good explanation - the component is not yet fully constructed.

The thing that bothers me is why it is OK to use the instance in my custom
IComponentInstantiationListener and it is not OK to do the same in
IAuthorizationStrategy#isInstantiationAuthorized() ?
If there is a javadoc explaining the possible problem (as for
IComponentInstantiationListener#onInstantiation()) then it is OK.

Even more - at
https://github.com/apache/wicket/blob/master/wicket-core/src/main/java/org/apache/wicket/Application.java#L276you
can see that right ater rejecting the *Class* we pass the *instance*
to
the UnauthorizedComponentInstantiationListener!

Martin Grigorov
Wicket Training and Consulting

Re: Passing Component or Class to IAuthorizationStrategy#isInstantiationAuthorized()

2013-12-20 Thread Igor Vaynberg

i am guessing that the id of the component would be useful for logging
in some cases, but i think it should just be passed in as an extra
argument if thats the case. something to fix in 7.0...

-igor


On Fri, Dec 20, 2013 at 11:44 AM, Martin Grigorov mgrigo...@apache.org wrote:
 and what about IUnauthorizedComponentInstantiationListener ?
 it receives the partially constructed object in case of rejection
 its javadoc states: The partially constructed component (only the id is
 guaranteed to be valid)
 but even Wicket sources use it (partially) wrong later:
 org.apache.wicket.authroles.authentication.AuthenticatedWebApplication#onUnauthorizedInstantiation
 casts the instance to a Page and passes it to
  
 org.apache.wicket.authroles.authentication.AuthenticatedWebApplication#onUnauthorizedPage(Page)
 Here we use just page.getClass() but specialization of this class may try
 to use the page instance for anything


 Martin Grigorov
 Wicket Training and Consulting


 On Fri, Dec 20, 2013 at 6:14 PM, Igor Vaynberg igor.vaynb...@gmail.comwrote:

 this is a security check, so the whole idea is that it is ran before
 any of the user's code in the constructor which may have side-effects.
 eg a constructor marking a record as ready to be deleted because a
 delete panel was instantiated. the class itself should be enough. even
 if you get an instance you cant use anything in it because its
 partially constructed. the question is if we do pass an instance how
 many users will bother reading javadoc? and out of those how many
 really understand how objects are constructed? i think we should close
 the issue as wont-fix, reading it It would be easier to decide if
 instantiation is authorized if one could access some properties of the
 component being constructed. which is exactly what you cannot/must
 not do because the object is only partially initialized, thus proving
 my point above.

 the ComponentInstantiationListener is a very special case where we
 make an exception. the entire point of this interface is to work with
 a partially constructed object and most users will never implement
 their own as opposed to the authorization strategy...

 -igor


 On Fri, Dec 20, 2013 at 12:53 AM, Martin Grigorov mgrigo...@apache.org
 wrote:
  Hi,
 
  The reporter of https://issues.apache.org/jira/browse/WICKET-5454 asked
 to
  pass the Component instance
  to  IAuthorizationStrategy#isInstantiationAuthorized() instead of just
 its
  class.
  I have no idea why the API has been designed this way but Carl-Eric gave
 a
  good explanation - the component is not yet fully constructed.
 
  The thing that bothers me is why it is OK to use the instance in my
 custom
  IComponentInstantiationListener and it is not OK to do the same in
  IAuthorizationStrategy#isInstantiationAuthorized() ?
  If there is a javadoc explaining the possible problem (as for
  IComponentInstantiationListener#onInstantiation()) then it is OK.
 
  Even more - at
 
 https://github.com/apache/wicket/blob/master/wicket-core/src/main/java/org/apache/wicket/Application.java#L276you
  can see that right ater rejecting the *Class* we pass the *instance*
  to
  the UnauthorizedComponentInstantiationListener!
 
 
  Martin Grigorov
  Wicket Training and Consulting

[jira] [Commented] (WICKET-663) enhance ichoicerenderer with id-choice object lookup

2013-12-19 Thread Igor Vaynberg (JIRA)


[ 
https://issues.apache.org/jira/browse/WICKET-663?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13853007#comment-13853007
 ] 

Igor Vaynberg commented on WICKET-663:
--

looks good. the only other thing i would consider is nuking the interface, 
there is no real point to having it...

 enhance ichoicerenderer with id-choice object lookup
 -

 Key: WICKET-663
 URL: https://issues.apache.org/jira/browse/WICKET-663
 Project: Wicket
  Issue Type: Improvement
Affects Versions: 1.3.0-final
Reporter: Igor Vaynberg
Assignee: Igor Vaynberg

 add object idtochoice(string id) to ichoicerenderer and add class 
 choicerenderer implements ichoicerenderer that encapsulate the default linear 
 search
 then we can remove method added in WICKET-348 to support a custom lookup



--
This message was sent by Atlassian JIRA
(v6.1.4#6159)

Re: wicket-el - is this a safe way to hook into wicket?

2013-12-19 Thread Igor Vaynberg

On Wed, Dec 18, 2013 at 9:40 PM, Steve Coughlan shadders@gmail.com wrote:
 A few weeks back I made a post about the first version of universal
 expression language for wicket.  Since then it's come quite a way.  The
 initial version hooked into by implementing IMarkupResourceStreamProvider
 for markup owning MarkupContainers (Panel, Page etc...) and by regenerating
 markup fragments for markup receiving MarkupContainers (ListView).
 Unfortunately due to the fact that the EL expressions need to be evaluated
 on every request this meant a huge performance hit (about 75% less than
 standard wicket) due to forcing wicket to constantly parse markup on every
 request cycle.

 The current evolution of wicket-el hooks in very differently.  My first
 preference was to create a dynamic version of Markup and MarkupFragment
 that replaces MarkupElements that contain EL expressions with a dynamic
 version.  Unfortuantely this was impossible because I need to subclass
 Markup (wicket uses a few case of 'instanceof Markup') and Markup has many
 final methods.  And simply wrapping all the MarkupElements isn't possible
 because RawMarkup is a final class and is also reference inside wicket with
 'instanceof'.

 So the only way I could think of to do it (which I've done and it works) is
 to create a subclass of Markup (ModifiableMarkup) that takes the original
 wicket-parsed markup, and adds all it's elements.  Then during the onRender
 phase EL enabled components call
 ModifiableMarkup.resolve(ExpressionResolver, ELParseMatchList) which
 internally replaces RawMarkup elements belonging to that compenent with an
 EL resolved version.  This is done just before calling super.onRender().
 Sounds ugly but it works and performance is now equal to standard wicket
 (in some cases can even be a little faster due to not needing
 PropertyModels).

 Because the Markup instances are now mutable I can't use wicket's markup
 cache as it's one per class and ModifiableMarkup.resolve method could
 easily be called by many threads at once.  So I've had to implement caching
 per thread/class combination.  i.e. ELPanel will have a cached instance of
 Markup for every thread.

 My question is twofold:
 1/ As I have no choice but to leave ModifiableMarkup mutable, what is the
 purpose of making Markup immutable?  From what I can see from browsing
 wicket source all it achieves is a bit of safety and releasing some
 resources from the backing XmlTags in the MarkupElements.  Is there any
 other purpose to it?  i.e. can you forsee any problems with using a mutable
 instance of Markup for rendering?

because its immutable it is thread-safe. making it mutable would add a
lot of complexity to make sure it is thread-safe.

-igor



 2/ Is the per thread/class caching strategy really safe?  The only way I
 could think it could be broken is if it was possible for the server to
 suspend a thread mid-render cycle and give another request use of that
 thread.  If that happened the new request would overwrite the markup
 expressions and the when the old resumed and expressions already resolved
 would have values from the the request that interrupted it.
 As far as I'm aware with the work I've done with Jetty and NIO connectors
 before this will only happen if you ask Jetty to do it while processing the
 request. Is this a possibility with wicket or can I rely on a complete
 render cycle to happen uninterrupted before the thread is reused for
 another request?

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

[jira] [Commented] (WICKET-663) enhance ichoicerenderer with id-choice object lookup

2013-12-18 Thread Igor Vaynberg (JIRA)


[ 
https://issues.apache.org/jira/browse/WICKET-663?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13851877#comment-13851877
 ] 

Igor Vaynberg commented on WICKET-663:
--

something to look into in wicket 7

 enhance ichoicerenderer with id-choice object lookup
 -

 Key: WICKET-663
 URL: https://issues.apache.org/jira/browse/WICKET-663
 Project: Wicket
  Issue Type: Improvement
Affects Versions: 1.3.0-final
Reporter: Igor Vaynberg
Assignee: Igor Vaynberg

 add object idtochoice(string id) to ichoicerenderer and add class 
 choicerenderer implements ichoicerenderer that encapsulate the default linear 
 search
 then we can remove method added in WICKET-348 to support a custom lookup



--
This message was sent by Atlassian JIRA
(v6.1.4#6159)

[jira] [Commented] (WICKET-663) enhance ichoicerenderer with id-choice object lookup

2013-12-18 Thread Igor Vaynberg (JIRA)


[ 
https://issues.apache.org/jira/browse/WICKET-663?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13852122#comment-13852122
 ] 

Igor Vaynberg commented on WICKET-663:
--

the way this works currently is:

lets say i pick a choice rendered as 17. when we need to resolve this back 
from the client string to the object we load up all the choices, go through 
them one by one, render the id using the renderer, and look for the match.

this is ok for most cases, but when you have multiple filters on the page each 
with 200ish choices this may get slow because not only are you doing a linear 
search across all options, you are also loading all options from the database 
or other potentially slow storages.

the idea behind this ticket is to make that reverse lookup (17-object) 
configurable. for large dropdowns a good optimization can be to simply cast 
17 to 17 and load the object with that id from the database.

there are two places for this kind of lookup: a method on the component and a 
method in the renderer.
imho the better place is the renderer because that is the more likely place for 
specializations to occur and since renderer is the thing that transcodes an 
object into a string representation it makes it logical that it handles the 
inverse. for example we have an EntityChoiceRenderer that knows how to pull the 
database id out of entities; it makes it a logical place to override the 
lookup. so we would have an EntityChoiceRenderer that knows how to deal with 
entities in a more complete way: encode them into html and decode them 
efficiently.

this would change the renderer from an interface into an abstract class, thus 
wicket 7.0, so it can provide the default linear lookup. maybe {code}T 
getObject(String value, IModelListT choices){code}. im not sure if the 
component instance would be useful in the method signature, my feeling that 
most likely not really and if its needed the user can pass it in manually.



 enhance ichoicerenderer with id-choice object lookup
 -

 Key: WICKET-663
 URL: https://issues.apache.org/jira/browse/WICKET-663
 Project: Wicket
  Issue Type: Improvement
Affects Versions: 1.3.0-final
Reporter: Igor Vaynberg
Assignee: Igor Vaynberg

 add object idtochoice(string id) to ichoicerenderer and add class 
 choicerenderer implements ichoicerenderer that encapsulate the default linear 
 search
 then we can remove method added in WICKET-348 to support a custom lookup



--
This message was sent by Atlassian JIRA
(v6.1.4#6159)

[jira] [Commented] (WICKET-5224) ModalWindow is not visible in Safari when opened from a link at the bottom of a large page


[ 
https://issues.apache.org/jira/browse/WICKET-5224?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13844409#comment-13844409
 ] 

Igor Vaynberg commented on WICKET-5224:
---

looks like this issue is back :/

 ModalWindow is not visible in Safari when opened from a link at the bottom of 
 a large page
 --

 Key: WICKET-5224
 URL: https://issues.apache.org/jira/browse/WICKET-5224
 Project: Wicket
  Issue Type: Bug
  Components: wicket-extensions
Affects Versions: 6.8.0
 Environment: Safari 5.1.7 (7534.57.2) Windows, Safari (iOS 6.1.3)
Reporter: Jered Myers
Assignee: Igor Vaynberg
 Fix For: 6.10.0, 7.0.0

 Attachments: safariscroll.zip

   Original Estimate: 1h
  Remaining Estimate: 1h

 I am not able to see a ModalWindow in Safari and I expect to see it centered 
 on my view port.
 Steps:
 1. Start with a large web page with a link to open the ModalWindow at the 
 bottom of the page.  You need a large page where you have to scroll down to 
 find the link.
 2. Click the link
 3. Observe that the mask for the ModalWindow displays, but the ModalWindow 
 does not.  Scrolling back up, re-sizing, and maximizing will still not 
 display the ModalWindow.



--
This message was sent by Atlassian JIRA
(v6.1.4#6159)

[jira] [Reopened] (WICKET-5224) ModalWindow is not visible in Safari when opened from a link at the bottom of a large page


 [ 
https://issues.apache.org/jira/browse/WICKET-5224?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Igor Vaynberg reopened WICKET-5224:
---


 ModalWindow is not visible in Safari when opened from a link at the bottom of 
 a large page
 --

 Key: WICKET-5224
 URL: https://issues.apache.org/jira/browse/WICKET-5224
 Project: Wicket
  Issue Type: Bug
  Components: wicket-extensions
Affects Versions: 6.8.0
 Environment: Safari 5.1.7 (7534.57.2) Windows, Safari (iOS 6.1.3)
Reporter: Jered Myers
Assignee: Igor Vaynberg
 Fix For: 6.10.0, 7.0.0

 Attachments: safariscroll.zip

   Original Estimate: 1h
  Remaining Estimate: 1h

 I am not able to see a ModalWindow in Safari and I expect to see it centered 
 on my view port.
 Steps:
 1. Start with a large web page with a link to open the ModalWindow at the 
 bottom of the page.  You need a large page where you have to scroll down to 
 find the link.
 2. Click the link
 3. Observe that the mask for the ModalWindow displays, but the ModalWindow 
 does not.  Scrolling back up, re-sizing, and maximizing will still not 
 display the ModalWindow.



--
This message was sent by Atlassian JIRA
(v6.1.4#6159)

[jira] [Updated] (WICKET-5224) ModalWindow is not visible in Safari when opened from a link at the bottom of a large page


 [ 
https://issues.apache.org/jira/browse/WICKET-5224?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Igor Vaynberg updated WICKET-5224:
--

Fix Version/s: (was: 6.10.0)
   6.13.0

 ModalWindow is not visible in Safari when opened from a link at the bottom of 
 a large page
 --

 Key: WICKET-5224
 URL: https://issues.apache.org/jira/browse/WICKET-5224
 Project: Wicket
  Issue Type: Bug
  Components: wicket-extensions
Affects Versions: 6.8.0
 Environment: Safari 5.1.7 (7534.57.2) Windows, Safari (iOS 6.1.3)
Reporter: Jered Myers
Assignee: Igor Vaynberg
 Fix For: 6.13.0, 7.0.0

 Attachments: safariscroll.zip

   Original Estimate: 1h
  Remaining Estimate: 1h

 I am not able to see a ModalWindow in Safari and I expect to see it centered 
 on my view port.
 Steps:
 1. Start with a large web page with a link to open the ModalWindow at the 
 bottom of the page.  You need a large page where you have to scroll down to 
 find the link.
 2. Click the link
 3. Observe that the mask for the ModalWindow displays, but the ModalWindow 
 does not.  Scrolling back up, re-sizing, and maximizing will still not 
 display the ModalWindow.



--
This message was sent by Atlassian JIRA
(v6.1.4#6159)

[jira] [Commented] (WICKET-5224) ModalWindow is not visible in Safari when opened from a link at the bottom of a large page


[ 
https://issues.apache.org/jira/browse/WICKET-5224?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13844420#comment-13844420
 ] 

Igor Vaynberg commented on WICKET-5224:
---

reverted the revert, seems to have fixed it.

 ModalWindow is not visible in Safari when opened from a link at the bottom of 
 a large page
 --

 Key: WICKET-5224
 URL: https://issues.apache.org/jira/browse/WICKET-5224
 Project: Wicket
  Issue Type: Bug
  Components: wicket-extensions
Affects Versions: 6.8.0
 Environment: Safari 5.1.7 (7534.57.2) Windows, Safari (iOS 6.1.3)
Reporter: Jered Myers
Assignee: Igor Vaynberg
 Fix For: 6.13.0, 7.0.0

 Attachments: safariscroll.zip

   Original Estimate: 1h
  Remaining Estimate: 1h

 I am not able to see a ModalWindow in Safari and I expect to see it centered 
 on my view port.
 Steps:
 1. Start with a large web page with a link to open the ModalWindow at the 
 bottom of the page.  You need a large page where you have to scroll down to 
 find the link.
 2. Click the link
 3. Observe that the mask for the ModalWindow displays, but the ModalWindow 
 does not.  Scrolling back up, re-sizing, and maximizing will still not 
 display the ModalWindow.



--
This message was sent by Atlassian JIRA
(v6.1.4#6159)

[jira] [Resolved] (WICKET-5224) ModalWindow is not visible in Safari when opened from a link at the bottom of a large page


 [ 
https://issues.apache.org/jira/browse/WICKET-5224?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Igor Vaynberg resolved WICKET-5224.
---

Resolution: Fixed

 ModalWindow is not visible in Safari when opened from a link at the bottom of 
 a large page
 --

 Key: WICKET-5224
 URL: https://issues.apache.org/jira/browse/WICKET-5224
 Project: Wicket
  Issue Type: Bug
  Components: wicket-extensions
Affects Versions: 6.8.0
 Environment: Safari 5.1.7 (7534.57.2) Windows, Safari (iOS 6.1.3)
Reporter: Jered Myers
Assignee: Igor Vaynberg
 Fix For: 6.13.0, 7.0.0

 Attachments: safariscroll.zip

   Original Estimate: 1h
  Remaining Estimate: 1h

 I am not able to see a ModalWindow in Safari and I expect to see it centered 
 on my view port.
 Steps:
 1. Start with a large web page with a link to open the ModalWindow at the 
 bottom of the page.  You need a large page where you have to scroll down to 
 find the link.
 2. Click the link
 3. Observe that the mask for the ModalWindow displays, but the ModalWindow 
 does not.  Scrolling back up, re-sizing, and maximizing will still not 
 display the ModalWindow.



--
This message was sent by Atlassian JIRA
(v6.1.4#6159)

[jira] [Resolved] (WICKET-5411) Improve AutoLabels by updating their CSS classes automatically during Ajax requests

2013-11-26 Thread Igor Vaynberg (JIRA)


 [ 
https://issues.apache.org/jira/browse/WICKET-5411?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Igor Vaynberg resolved WICKET-5411.
---

Resolution: Fixed

 Improve AutoLabels by updating their CSS classes automatically during Ajax 
 requests
 ---

 Key: WICKET-5411
 URL: https://issues.apache.org/jira/browse/WICKET-5411
 Project: Wicket
  Issue Type: Improvement
  Components: wicket
Reporter: Igor Vaynberg
Assignee: Igor Vaynberg
 Fix For: 6.13.0, 7.0.0


 The problem with auto labels is that once they are rendered the only way to 
 update their `error`/`required` css classes during ajax requests is to update 
 some parent since auto components cannot be targeted directly. however, when 
 dealing with forms we may not necessarily want to repaint components because 
 we may lose state.
 This issue solves the problem by tracking state changes in form components 
 that have auto labels and updating their css classes on all ajax requests.
 disabled by default in 6.13 (to enable override 
 WebApplication#getUpdateAutoLabelsOnAjaxRequests() ), always enabled in 7.0



--
This message was sent by Atlassian JIRA
(v6.1#6144)

Re: Enfocing INPUT field names to respect hCard formats

2013-11-17 Thread Igor Vaynberg

override getInputName() and return the string you want.

-igor

On Sun, Nov 17, 2013 at 5:21 AM, Arjun Dhar dhar...@yahoo.com wrote:
 http://microformats.org/wiki/hcard-input-examples#person_billing_shipping_input

 To ensure browsers can Auto fill Input form fields for E-Commerce forms and
 common fields. I want to ensure the fieldNames match this convention.

 I tried a test class something like


 ..but it does not respect the input field provided; specially if the INput
 field is Bound via CompoundPropertyModel. Say shippingAddress contains city.
 Then the field is still named shippingAddress:city.

 How best to overcome this so I can standardize my field Names via HTML.
 I dont want to be writing HTML field names in Java code. That would suck.

 thanks




 -
 Software documentation is like sex: when it is good, it is very, very good; 
 and when it is bad, it is still better than nothing!
 --
 View this message in context: 
 http://apache-wicket.1842946.n4.nabble.com/Enfocing-INPUT-field-names-to-respect-hCard-formats-tp4662465.html
 Sent from the Users forum mailing list archive at Nabble.com.

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


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

[jira] [Commented] (WICKET-5417) this.replaceWith is broken when called from onInitialize

2013-11-15 Thread Igor Vaynberg (JIRA)


[ 
https://issues.apache.org/jira/browse/WICKET-5417?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13823752#comment-13823752
 ] 

Igor Vaynberg commented on WICKET-5417:
---

whats the usecase for component replacing itself during oninitialize()? it 
doesnt seem valid to me...

 this.replaceWith is broken when called from onInitialize
 

 Key: WICKET-5417
 URL: https://issues.apache.org/jira/browse/WICKET-5417
 Project: Wicket
  Issue Type: Bug
  Components: wicket
Affects Versions: 6.12.0
Reporter: Ryan Dearing
Assignee: Martin Grigorov
 Attachments: WICKET-5417.patch, replacewithbug.tgz


 When calling this.replaceWith within the onInitialize method, wicket throws 
 an exception:
 Last cause: org.apache.wicket.Component has not been properly initialized. 
 Something in the hierarchy of com.mycompany.PanelA has not called 
 super.onInitialize() in the override of onInitialize() method
   
 This happens because detach is called on the panel being replaced which 
 clears Component.request flags (sets to 0) which causes the exception on line 
 864 of Component.java:
 if (!getRequestFlag(RFLAG_INITIALIZE_SUPER_CALL_VERIFIED)) {
 // throws here
 }



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Reopened] (WICKET-5418) PropertyValidator ignoring groups with the @NotNull annotation only

2013-11-15 Thread Igor Vaynberg (JIRA)


 [ 
https://issues.apache.org/jira/browse/WICKET-5418?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Igor Vaynberg reopened WICKET-5418:
---


 PropertyValidator ignoring groups with the @NotNull annotation only
 ---

 Key: WICKET-5418
 URL: https://issues.apache.org/jira/browse/WICKET-5418
 Project: Wicket
  Issue Type: Bug
  Components: wicket-bean-validation
Affects Versions: 6.12.0
 Environment: MacOSX, Glassfish
Reporter: Jesus Mireles
Assignee: Igor Vaynberg
  Labels: validation
 Attachments: BeanValidation.zip


 When using groups in your JSR303 compliant classes, Wicket does not honor the 
 groups for the @NotNull annotation.  



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Resolved] (WICKET-5418) PropertyValidator ignoring groups with the @NotNull annotation only

2013-11-15 Thread Igor Vaynberg (JIRA)


 [ 
https://issues.apache.org/jira/browse/WICKET-5418?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Igor Vaynberg resolved WICKET-5418.
---

   Resolution: Fixed
Fix Version/s: 7.0.0
   6.13.0

 PropertyValidator ignoring groups with the @NotNull annotation only
 ---

 Key: WICKET-5418
 URL: https://issues.apache.org/jira/browse/WICKET-5418
 Project: Wicket
  Issue Type: Bug
  Components: wicket-bean-validation
Affects Versions: 6.12.0
 Environment: MacOSX, Glassfish
Reporter: Jesus Mireles
Assignee: Igor Vaynberg
  Labels: validation
 Fix For: 6.13.0, 7.0.0

 Attachments: BeanValidation.zip


 When using groups in your JSR303 compliant classes, Wicket does not honor the 
 groups for the @NotNull annotation.  



--
This message was sent by Atlassian JIRA
(v6.1#6144)

Re: Future of wicket-cdi

2013-11-13 Thread Igor Vaynberg

i agree we should restart with the original implementation and
incrementally introduce the new features - thats what i proposed in
the original pull request.

i am not a big fan of having the application instance managed. what is
the value of this? it can be injected using noncontextual just like
everything else...

-igor


On Wed, Nov 13, 2013 at 1:19 PM, Emond Papegaaij
emond.papega...@gmail.com wrote:
 Hi all,

 You probably noticed the the flood of emails regarding wicket-cdi these
 last few days, which IMHO is good, because it means wicket-cdi is alive.
 However, the current status is that the current (old) implementation of
 wicket-cdi works badly with CDI 1.1 and the experimental (new) version is
 broken in various ways. This is not good, as there is no good
 implementation to use for CDI 1.1 users.

 I've reviewed parts of the code in wicket-cdi-1.1 and noticed the following
 problems:
 - Featuritis: it supports all kinds of usecases nobody is every going to
 use, such as: partly managed applications, per-conversation
 auto-conversions, per-conversation propagation, package ignores, switched
 to enable/disable injection on almost everyting.
 - Buggy: auto-conversations are broken for everything but pages, injection
 in anonymous classes was broken, probably more.
 - Too much state: configuration options are copied all over the place,
 objects with different lifecycles share state.
 - Too much injection: everything is injected, which makes it almost
 impossible to see what's linked to what.

 I've also noticed some very nices features:
 - CDI 1.1 support with conversations via the Weld API
 - Management of the application and the Wicket-cdi configuration by cdi.
 - Better implementation of NonContextual injection, using caches.
 - Better testcases

 The experimental code is in such a state that is it almost impossible to
 cleanup. On the other hand, I do not want to loose some of the new
 features. Therefore, I propose the following: restart the wicket-cdi-1.1
 implementation, starting from the current wicket-cdi implementation and
 reintroducing the features one-by-one. Also, I would like to remove some of
 the existing features, like most of the toggle-switches, and I would like
 to make the new CdiWebApplicationFactory mandatory to always have the
 application be managed. All this will still be experimental in wicket 6,
 but perhaps it can be made the default in 7. As we at Topicus are currently
 starting the migration from JBoss 7.1 to WildFly 8, I can work on this 1 or
 2 days a week.

 Let me know what you think,
 Emond

Re: Future of wicket-cdi

2013-11-13 Thread Igor Vaynberg

On Wed, Nov 13, 2013 at 1:43 PM, John Sarman johnsar...@gmail.com wrote:
 So let me filter through injection of App.
 CdiWicketFilter gets injected factory.
 @Inject
 CdiWebApplicationFactory applicationFactory;

 the Factory get injected the following
 @Inject
 @Any
 InstanceWebApplication applications;
 @Inject
 CdiConfiguration cdiConfiguration;

 If there is only one application in a war then the web.xml only needs
 filter
 filter-nameCdiApplication/filter-name
 filter-classorg.apache.wicket.cdi.CdiWicketFilter/filter-class
 /filter
 if multiple then additional
   init-param
   param-nameapplicationName/param-name
   param-valueCdiExample/param-value
 /init-param
 and @WicketApp(CdiExample) added.

i dont see this as an advantage. specifying a class name is trivial.

further you are assuming i am running inside a container that has its
filter's managed by cdi, this is not always the case so using your cdi
filter would fail. one would have to fall back on wicket-filter and
specify the cdi application factory that you provide, but that class
itself assumes it is managed by cdi, so it wont work either. so you
did not leave an escape hatch for people using simple containers.

my original code may not be cdi-pretty but it works for all
containers out there - cdi managed or not.


 No need to start up CDI in init()

we do not start up cdi in init, we configure how it interacts with the
wicket application. settings such things as conversation propagation
mode, etc.

 Start using CDI.

 For apps that may want to add CDI they just
 filter
 filter-nameCdiApplication/filter-name
 filter-classorg.apache.wicket.cdi.CdiWicketFilter/filter-class
 /filter

 Start using CDI.

 So I still defend injection of the Cdi Wicket integration code.

 Also if it is removed then code will have to be added to differentiate
 which cdi implementation is being used.

 Currently CDI does this so long as two different CDI implementation jars
 aren't add, which would be ambiguous.

this will still work. you can still inject the configuration using
noncontextual and pull the right instance. or use jdk's ServiceLoader
to find all implementors.

my problem with this is that there is a specific lifecycle to the
application that is not managed by cdi. it is not safe to use the
application instance after it has been created, you have to wait until
wicket calls certain methods on it.

by making it managed you are giving the impression that it is safe to
inject the instance and use it in various places. it is not, not until
it has been properly configured. i do not want to debug cases where my
configuration changes to the application disappear because my code got
that injected the application and configured it got called before
internalInit(). either create a subcpass with @PostConstruct that
configures the application - which wont work - people dont like using
subclasses - or create a provider.

-igor

 On Wed, Nov 13, 2013 at 4:31 PM, Igor Vaynberg igor.vaynb...@gmail.comwrote:

 i agree we should restart with the original implementation and
 incrementally introduce the new features - thats what i proposed in
 the original pull request.

 i am not a big fan of having the application instance managed. what is
 the value of this? it can be injected using noncontextual just like
 everything else...

 -igor


 On Wed, Nov 13, 2013 at 1:19 PM, Emond Papegaaij
 emond.papega...@gmail.com wrote:
  Hi all,
 
  You probably noticed the the flood of emails regarding wicket-cdi these
  last few days, which IMHO is good, because it means wicket-cdi is alive.
  However, the current status is that the current (old) implementation of
  wicket-cdi works badly with CDI 1.1 and the experimental (new) version is
  broken in various ways. This is not good, as there is no good
  implementation to use for CDI 1.1 users.
 
  I've reviewed parts of the code in wicket-cdi-1.1 and noticed the
 following
  problems:
  - Featuritis: it supports all kinds of usecases nobody is every going to
  use, such as: partly managed applications, per-conversation
  auto-conversions, per-conversation propagation, package ignores, switched
  to enable/disable injection on almost everyting.
  - Buggy: auto-conversations are broken for everything but pages,
 injection
  in anonymous classes was broken, probably more.
  - Too much state: configuration options are copied all over the place,
  objects with different lifecycles share state.
  - Too much injection: everything is injected, which makes it almost
  impossible to see what's linked to what.
 
  I've also noticed some very nices features:
  - CDI 1.1 support with conversations via the Weld API
  - Management of the application and the Wicket-cdi configuration by cdi.
  - Better implementation of NonContextual injection, using caches.
  - Better testcases
 
  The experimental code is in such a state that is it almost impossible to
  cleanup. On the other hand, I do not want to loose some of the new
  features. Therefore, I propose

Re: Future of wicket-cdi

2013-11-13 Thread Igor Vaynberg

On Wed, Nov 13, 2013 at 2:42 PM, John Sarman johnsar...@gmail.com wrote:

snip

 further you are assuming i am running inside a container that has its
 filter's managed by cdi, this is not always the case so using your cdi
 filter would fail. one would have to fall back on wicket-filter and


 I am 100% assuming that since you just included wicket-weld in the build.
 Therefore you do have a managed container at that point.

we deploy in tomcat. we include weld as a war-dependency, not as
tomcat dependency, therefore in our deployments filters are not
injected. i assume this is how most people deploying to tomcat or
jetty have it set up. are we dropping support for those people?

 specify the cdi application factory that you provide, but that class
 itself assumes it is managed by cdi, so it wont work either. so you
 did not leave an escape hatch for people using simple containers.

 my original code may not be cdi-pretty but it works for all
 containers out there - cdi managed or not.

 I couldn't have got anywhere without your code.  I was pretty to me m_BLAH
 m_BLAT is ugly.
 I'm an ole school constructor versus setter myself, Object is ready at
 Construction. But with CDI I get that guarantee with the no arg, easier to
 Mock.

unfortunately WebApplication instances are not ready at construction,
that is the problem.

  No need to start up CDI in init()

 we do not start up cdi in init, we configure how it interacts with the
 wicket application. settings such things as conversation propagation
 mode, etc.


 Yeah but that starts it otherwise the Injectors are not set up and it
 wouldn't work(inject).

in our deployment we have a servlet listener that bootstraps cdi so
its available to other servlets, not just wicket. in
application.init() you simply configure wicket to use cdi by giving it
the bean manager. this approach also works in environments with no
JNDI where you cannot simply pull a bean manager out of some store but
have to use a custom mechanism to retrieve it. imagine an application
with an embedded servlet container.

snip

 my problem with this is that there is a specific lifecycle to the
 application that is not managed by cdi. it is not safe to use the
 application instance after it has been created, you have to wait until
 wicket calls certain methods on it.


 Yeah, I do wait. That's why I used the Factory.  Only thing that is done is
 some member variables are populated. I did not override Wicket management,
 just injected some dependencies.

you wait, but the users may not. now that application instance is
managed by cdi why cant i do something like this:

class WebConfigurator {
  @Inject WebApplication application;

   private void configure(@Observes ContainerStartEvent) {
   application.getMarkupSettings().setFoo(bar);
}
}

after all, this would be the CDI-way of configuring the web
application instance. but this does not work because webapplication
instance is managed by wicket and not by cdi. so if this code runs
before the filter my settings would be overwritten by internalInit()
call.

this is the impedance mismatch i do not like. artifacts whose
lifecycle is managed by wicket should not also be managed by cdi, or
if they are there should be a provider that creates instances and
knows how to correctly configure it.

so in the case above when my configurator is called the provider
should bootstrap the wicket application, call internalinit(), and have
it all ready for my code.

 by making it managed you are giving the impression that it is safe to
 inject the instance and use it in various places. it is not, not until
 it has been properly configured. i do not want to debug cases where my
 configuration changes to the application disappear because my code got
 that injected the application and configured it got called before
 internalInit(). either create a subcpass with @PostConstruct that
 configures the application - which wont work - people dont like using
 subclasses - or create a provider.


 Like I said Cdi injects some members, the Factory returns the application
 to WicketFilter and the same lifecycle commences.

see point above, by making it managed you are making it available for
other code to consume as injectable.

-igor

Re: Future of wicket-cdi

2013-11-13 Thread Igor Vaynberg

On Wed, Nov 13, 2013 at 4:18 PM, John Sarman johnsar...@gmail.com wrote:
 So maybe we should just remove all the scoped classes.  Add the code to
 automagically find a cdi impl, weld etc.

yeah, we can use jdk's ServiceLoader to see whats on the classpath.

 Create custom factory that
 CdiConfiguration is set up via parameters in web.xml.

im not sure this is necessary, it will make it more difficult for
deployments where its hard to find the bean manager (ie its not in a
well known place in jndi). the only part this saves is calling new
CdiConfiguration()configure(this) in application init, right? i
actually like that part because it makes it clear what options i set -
propagation, etc.

Then after
 instantiating the App pass it to the NonContextual for injection.

see below

  Rewrite
 the tests to work with new technique. This allows app injection with Wicket
 in charge, before init. And everything works the same.  That may be a
 better roadmap for the rewrite.  Also that does eliminate the need for the
 weld listener.

 Time to start planning on a rewrite, I am not married to the Injection,
 just like to add @Resource(mailSessionJNDI) to my Application and use it in
 init().

the application is already injected, thats why i dont understand why
you had a problem with the original way of doing things...

public class MyApplication extends WebApplication {
 @Resource resource;

  public void init() {
 // do some configuration

 new CdiConfiguration().configure(this);

 // after the line above the application is injected and resource
is now available. by default injectApplication bit in CdiConfiguration
is set to true and it passes the instance through NonContextual.

 resource.doSomething();
   }
}

-igor




 On Wed, Nov 13, 2013 at 6:40 PM, Igor Vaynberg igor.vaynb...@gmail.comwrote:

 On Wed, Nov 13, 2013 at 2:42 PM, John Sarman johnsar...@gmail.com wrote:

 snip

  further you are assuming i am running inside a container that has its
  filter's managed by cdi, this is not always the case so using your cdi
  filter would fail. one would have to fall back on wicket-filter and
 
 
  I am 100% assuming that since you just included wicket-weld in the build.
  Therefore you do have a managed container at that point.

 we deploy in tomcat. we include weld as a war-dependency, not as
 tomcat dependency, therefore in our deployments filters are not
 injected. i assume this is how most people deploying to tomcat or
 jetty have it set up. are we dropping support for those people?


  specify the cdi application factory that you provide, but that class
  itself assumes it is managed by cdi, so it wont work either. so you
  did not leave an escape hatch for people using simple containers.
 
  my original code may not be cdi-pretty but it works for all
  containers out there - cdi managed or not.
 
  I couldn't have got anywhere without your code.  I was pretty to me
 m_BLAH
  m_BLAT is ugly.
  I'm an ole school constructor versus setter myself, Object is ready at
  Construction. But with CDI I get that guarantee with the no arg, easier
 to
  Mock.

 unfortunately WebApplication instances are not ready at construction,
 that is the problem.


   No need to start up CDI in init()
 
  we do not start up cdi in init, we configure how it interacts with the
  wicket application. settings such things as conversation propagation
  mode, etc.
 
 
  Yeah but that starts it otherwise the Injectors are not set up and it
  wouldn't work(inject).

 in our deployment we have a servlet listener that bootstraps cdi so
 its available to other servlets, not just wicket. in
 application.init() you simply configure wicket to use cdi by giving it
 the bean manager. this approach also works in environments with no
 JNDI where you cannot simply pull a bean manager out of some store but
 have to use a custom mechanism to retrieve it. imagine an application
 with an embedded servlet container.


 snip

  my problem with this is that there is a specific lifecycle to the
  application that is not managed by cdi. it is not safe to use the
  application instance after it has been created, you have to wait until
  wicket calls certain methods on it.
 
 
  Yeah, I do wait. That's why I used the Factory.  Only thing that is done
 is
  some member variables are populated. I did not override Wicket
 management,
  just injected some dependencies.

 you wait, but the users may not. now that application instance is
 managed by cdi why cant i do something like this:

 class WebConfigurator {
   @Inject WebApplication application;

private void configure(@Observes ContainerStartEvent) {
application.getMarkupSettings().setFoo(bar);
 }
 }

 after all, this would be the CDI-way of configuring the web
 application instance. but this does not work because webapplication
 instance is managed by wicket and not by cdi. so if this code runs
 before the filter my settings would be overwritten by internalInit()
 call

Re: weld conversation propagation page

2013-11-13 Thread Igor Vaynberg

this is the desired behavior. see conversation propagation settings.
by default conversations are only propagated to non-bookmarkable
pages.

-igor

On Wed, Nov 13, 2013 at 4:36 AM, brazz alexander.li...@man.eu wrote:
 Hi,

 after spending a hard time debugging i found this problem:

 i have to pages:
 FirstPage.class
 SecondPage.class

 on FirstPage.class i create a new conversation with conversation.begin();
 and on FirstPage.class i have a link:

 *setResponsePage(SecondPage.class);*

 this link results in a new transient Conversation on SecondPage.class

 if i create a new instance in setResponsePage():
 *setResponsePage(new SecondPage());*

 the conversation is propagated correctly ot SecondPage.class.

 As i am new to cdi and weld i cannot really estimate if this is a bug or
 desired behavior:

 Thanks for any explanations.




 --
 View this message in context: 
 http://apache-wicket.1842946.n4.nabble.com/weld-conversation-propagation-page-tp4662389.html
 Sent from the Users forum mailing list archive at Nabble.com.

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


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

[jira] [Commented] (WICKET-5411) Improve AutoLabels by updating their CSS classes automatically during Ajax requests

2013-11-12 Thread Igor Vaynberg (JIRA)


[ 
https://issues.apache.org/jira/browse/WICKET-5411?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13820226#comment-13820226
 ] 

Igor Vaynberg commented on WICKET-5411:
---

i wasnt going to close it until i tested it in our app to make sure it works 
for complex usecases...

 Improve AutoLabels by updating their CSS classes automatically during Ajax 
 requests
 ---

 Key: WICKET-5411
 URL: https://issues.apache.org/jira/browse/WICKET-5411
 Project: Wicket
  Issue Type: Improvement
  Components: wicket
Reporter: Igor Vaynberg
Assignee: Igor Vaynberg
 Fix For: 6.13.0, 7.0.0


 The problem with auto labels is that once they are rendered the only way to 
 update their `error`/`required` css classes during ajax requests is to update 
 some parent since auto components cannot be targeted directly. however, when 
 dealing with forms we may not necessarily want to repaint components because 
 we may lose state.
 This issue solves the problem by tracking state changes in form components 
 that have auto labels and updating their css classes on all ajax requests.
 disabled by default in 6.13 (to enable override 
 WebApplication#getUpdateAutoLabelsOnAjaxRequests() ), always enabled in 7.0



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Resolved] (WICKET-5411) Improve AutoLabels by updating their CSS classes automatically during Ajax requests

2013-11-12 Thread Igor Vaynberg (JIRA)


 [ 
https://issues.apache.org/jira/browse/WICKET-5411?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Igor Vaynberg resolved WICKET-5411.
---

Resolution: Fixed

 Improve AutoLabels by updating their CSS classes automatically during Ajax 
 requests
 ---

 Key: WICKET-5411
 URL: https://issues.apache.org/jira/browse/WICKET-5411
 Project: Wicket
  Issue Type: Improvement
  Components: wicket
Reporter: Igor Vaynberg
Assignee: Igor Vaynberg
 Fix For: 6.13.0, 7.0.0


 The problem with auto labels is that once they are rendered the only way to 
 update their `error`/`required` css classes during ajax requests is to update 
 some parent since auto components cannot be targeted directly. however, when 
 dealing with forms we may not necessarily want to repaint components because 
 we may lose state.
 This issue solves the problem by tracking state changes in form components 
 that have auto labels and updating their css classes on all ajax requests.
 disabled by default in 6.13 (to enable override 
 WebApplication#getUpdateAutoLabelsOnAjaxRequests() ), always enabled in 7.0



--
This message was sent by Atlassian JIRA
(v6.1#6144)

Re: Eclipse formatting, was: Martin's wicket pull request

2013-11-12 Thread Igor Vaynberg

any progress Martijn?

-igor

On Sun, Nov 10, 2013 at 12:49 AM, Martijn Dashorst
martijn.dasho...@gmail.com wrote:
 We can let the eclipse plugin automatically add the project settings
 if we upload a jar to maven central with our configuration.

 plugin
 artifactIdmaven-eclipse-plugin/artifactId
 version2.9/version
 inheritedtrue/inherited
 configuration
 downloadSourcestrue/downloadSources
 downloadJavadocfalse/downloadJavadoc
 ajdtVersion${java.version}/ajdtVersion
 additionalConfig
 file
 name.settings/edu.umd.cs.findbugs.plugin.eclipse.prefs/name
 location/edu.umd.cs.findbugs.plugin.eclipse.prefs/location
 /file
 file
 name.settings/org.eclipse.core.resources.prefs/name
 location/org.eclipse.core.resources.prefs/location
 /file
 file
 name.settings/org.eclipse.jdt.apt.core.prefs/name
 location/org.eclipse.jdt.apt.core.prefs/location
 /file
 file
 name.settings/org.eclipse.jdt.core.prefs/name
 location/org.eclipse.jdt.core.prefs/location
 /file
 file
 name.settings/org.eclipse.jdt.ui.prefs/name
 location/org.eclipse.jdt.ui.prefs/location
 /file
 file
 name.settings/org.eclipse.wst.validation.prefs/name
 location/org.eclipse.wst.validation.prefs/location
 /file
 file
 name.settings/org.maven.ide.eclipse.prefs/name
 location/org.maven.ide.eclipse.prefs/location
 /file
 /additionalConfig
 /configuration
 dependencies
 dependency
 groupIdnl.topicus.onderwijs/groupId
 artifactIdeclipse-settings/artifactId
 version2012.2.2/version
 /dependency
 /dependencies
 /plugin

 On Sun, Nov 10, 2013 at 12:45 AM, Igor Vaynberg igor.vaynb...@gmail.com 
 wrote:
 yes, making it a workspace default messes up other projects...

 this way every time i import a project into the eclipse workspace i
 have to go and manually set the formatter on every module, which as
 you can imagine is not optimal

 -igor

 On Sat, Nov 9, 2013 at 1:40 PM, Martin Grigorov mgrigo...@apache.org wrote:
 But you have to import the xml just once, right ? It is not a big deal.
 Or the problem is that the xml messes up the other projects in your
 workspace ?



 On Sat, Nov 9, 2013 at 7:24 AM, Igor Vaynberg 
 igor.vaynb...@gmail.comwrote:

 it is really frustrating that i have to do this manually now. before
 all i had to do was checkout the project and it was all set. wicket
 shares my workspace with other projects so the workspace-default is
 not going to work.

 can we drop the format def on wicket.apache.org and configure the
 maven plugin to set it up:

 http://maven.apache.org/plugins/maven-eclipse-plugin/examples/load-code-styles.html

 -igor

 On Fri, Nov 8, 2013 at 12:56 AM, Martin Grigorov mgrigo...@apache.org
 wrote:
  I'll test this soon.
  I'll update the docs for IDEA too if needed.
 
 
  On Thu, Nov 7, 2013 at 11:02 AM, Sven Meier s...@meiers.net wrote:
 
  Thanks, I've added a hint to the Idea instructions.
 
  Regards
  Sven
 
 
  On 11/06/2013 10:12 AM, Vojtěch Krása wrote:
 
  You should also specify values for Class count to use import with '*'
  and
  Names count to use static import with '*', since these values are
  not in EclipseCodeFormat.xml,
  and differs between Idea and Eclipse by default.
 
 
  V.
 
 
  2013/11/6 Sven Meier s...@meiers.net
 
   Hi all,
 
  I removed all org.eclipse.jdt.[core|ui].prefs from the repo as
  discussed.
  EclipseCodeFormat.xml is updated now to our latest and greatest code
  format
  (which might differ between 6.x and master).
 
  Eclipse users should run mvn eclipse:eclipse to regenerate
  org.eclipse.jdt.core.prefs, then (re-)import EclipseCodeFormat.xml and
  use
  it as the default for your Wicket workspace(s).
  I've added a paragraph about the recommended Eclipse setup here:
  http://wicket.apache.org/learn/ides.html
 
  Could an Idea user please confirm that the format plugin (
  http://plugins.jetbrains.com/plugin/6546) works as expected?
 
  Regards
  Sven
 
  On 11/05/2013 12:05 PM, Martin Grigorov wrote:
 
   On Tue, Nov 5, 2013 at 1:01 PM, Sven Meier s...@meiers.net wrote:
 
IMHO we should have one authoritative source for our source format
  only.
 
  Whether this is EclipseCodeFormat.xml or something else can be
 dicussed
  on
  the other mail thread.
 
  Currently all org.eclipse.jdt.core.prefs have already diverged from
  EclipseCodeFormat.xml (perhaps they even differ between each
 other?),
  so
  I'm +1 to remove those settings from the repo as Martin has
 suggested.
  I can live with having to configure my Wicket workspace(s) once by
  importing EclipseCodeFormat.xml.
 
  So if no one objects, I'll update EclipseCodeFormat.xml from the
  current
  settings in wicket-core and apply Martin's patch afterwards.
 
   I'm +1.
  With the plugin that Rusi suggested in the other thread I can import
 EclipseCodeFormat.xml in Intellij IDEA and hopefully the
 formatting
  will
  be the same for all of us.
 
 
 
   Sven
 
 
 
  On 11/04/2013 04:42 PM, Martin Funk wrote:
 
not quite
 
  if the org.eclipse.jdt.ui.prefs are not present eclipse will fall
 back

Re: remove recently merged cdi 1.1 from 6.x

2013-11-12 Thread Igor Vaynberg

the point on INonContextualManager was to internalize NonContextual -
in case cdi implementation provides a better way to perform
non-contextual injection.

now that NonContextualManager is @ApplicationScoped and
CdiConfiguration does not have a setter for it this functionality is
lost. and even if cdi configuration had a setter, there is no longer a
guarantee that someone did not inject one and use it before a new one
was set on the configuration. that is why these things were not
managed by cdi in the initial code...

-igor


On Mon, Nov 11, 2013 at 11:16 AM, John Sarman johnsar...@gmail.com wrote:
 Also Noncontextual.of is never used anywhere except in the Wicket CDI api,
 so I disagree. It solely used by the NonContextualManager which is
 ApplicationScoped and the BeanManager is injected.  The CdiCleanup also
 uses it and is passed the BeanManager during configuration, both cases do
 not make it unnice since it is an internal api.


 On Mon, Nov 11, 2013 at 2:11 PM, John Sarman johnsar...@gmail.com wrote:

 Actually I just changed them back to the way Igor originally implemented
 it.


 On Mon, Nov 11, 2013 at 2:10 PM, Emond Papegaaij 
 emond.papega...@gmail.com wrote:

 Hi John,

 There is nothing wrong with looking up the BeanManager in a static
 context.
 It's just that the current implementation of
 CDI.current().getBeanManager()
 is broken in Weld. I expect this to be fixed soon. The workaround moves
 the
 lookup to a single place and tries a portable JNDI lookup first. This will
 work in all EE containers. More importantly, the user doesn't notice the
 workaround at all.

 Your commit changes the signature of NonContextual.of. You are now
 required
 to pass in the BeanManager, which is not very nice, because NonContextual
 is to do CDI injection in places where CDI can't do it for you. In these
 places, you often don't have a BeanManager available. I think the
 workaround should stay until the bug is fixed in Weld.

 Best regards,
 Emond


 On Mon, Nov 11, 2013 at 7:45 PM, John Sarman johnsar...@gmail.com
 wrote:

  Edmond,
  I updated the cdi code to not ever use the CDI.current().   I reworked
 your
  test earlier to just inject the BeanManager and that properly allows the
  multiple wars to see the InjectableTargets from a shared lib.   I could
  only conclude that CDI.current should not be called from a static
 method,
  so instead of joining the weld team or submitting an issue, I just
 removed
  that possibility from the code.  That latest code is in
  https://github.com/jsarman/wicket master branch. This also removed the
  need
  for the BeanManagerLookup workaround.
 
 
 
 
  On Mon, Nov 11, 2013 at 8:49 AM, John Sarman johnsar...@gmail.com
 wrote:
 
   Nevermind, I should not write emails this early, without an unsend.
   Servlet A should see same BeanManager as Servlet B, if both servlets
 are
   deployed from same war file.  That is ApplicationScoped.
  
  
   On Mon, Nov 11, 2013 at 8:47 AM, John Sarman johnsar...@gmail.com
  wrote:
  
   Ok, I read through your test code, so if you are saying that servlet
 a
   gets same beanmanager as servlet b then yeah thats bad.
  
  
   On Mon, Nov 11, 2013 at 8:44 AM, John Sarman johnsar...@gmail.com
  wrote:
  
   I was looking at your bug, but in the case you specified where the
   cached BeanManager is passed, seems to be the correct behavior
 because
  the
   CdiConfiguration is ApplicationScoped.  The CDI class states this:
   /**
* Get the CDI BeanManager for the current context
*
* @return
*/
   public abstract BeanManager getBeanManager();
  
   So the cached BeanManager passed back is because it is accessed in
 an
   ApplicationScoped class.   ApplicationScoped != Wickets Application
  scope.
  
  
  
  
  
   On Mon, Nov 11, 2013 at 8:26 AM, Emond Papegaaij 
   emond.papega...@topicus.nl wrote:
  
   You are right, InitialContext.lookup was returning null. I've
 fixed it
   by falling
   back to CDI.current().getBeanManager() in that case. The
 workaround is
   needed because of a very nasty bug in de Wildfly-Weld integration:
   https://issues.jboss.org/browse/WFLY-2481
  
   Best regards,
   Emond
  
   On Monday 11 November 2013 08:18:20 John Sarman wrote:
As far as the Test failing, I think the workaround code to use
 jndi
   first
may have caused the test to fail.  So far it seems that all the
   request
pull 50 is not in the 6 branch.
What forced the need for the workaround?
   
John
   
On Mon, Nov 11, 2013 at 8:00 AM, John Sarman
   johnsar...@gmail.com wrote:
 It is not a forced requirement, just an option for full cdi
   injection.


 On Mon, Nov 11, 2013 at 3:50 AM, Emond Papegaaij 

 emond.papega...@topicus.nl wrote:
 Hi John,

 I've just merged the pull request in the wicket-6.x branch
 (still
   under
 experimental). The version still is 0.2-SNAPSHOT, as the
 versions
   are
 automatically increased on release. The

Re: git commit: WICKET-5411 auto label auto update during ajax

2013-11-09 Thread Igor Vaynberg

i suppose that bit of js can be rewritten to use pure dom, but has
anyone actually ever implemented wicket-event.js and wicket-ajax.js
using anything other then jquery?

-igor

On Sat, Nov 9, 2013 at 1:34 PM, Martin Grigorov mgrigo...@apache.org wrote:
 On Sat, Nov 9, 2013 at 8:49 AM, ivaynb...@apache.org wrote:

 Updated Branches:
   refs/heads/wicket-6.x 4e9a83fdc - a73209bea


 WICKET-5411 auto label auto update during ajax


 Project: http://git-wip-us.apache.org/repos/asf/wicket/repo
 Commit: http://git-wip-us.apache.org/repos/asf/wicket/commit/a73209be
 Tree: http://git-wip-us.apache.org/repos/asf/wicket/tree/a73209be
 Diff: http://git-wip-us.apache.org/repos/asf/wicket/diff/a73209be

 Branch: refs/heads/wicket-6.x
 Commit: a73209beab8814a06f2e085384ad87bdf1fda212
 Parents: 4e9a83f
 Author: Igor Vaynberg igor.vaynb...@gmail.com
 Authored: Fri Nov 8 22:48:22 2013 -0800
 Committer: Igor Vaynberg igor.vaynb...@gmail.com
 Committed: Fri Nov 8 22:48:22 2013 -0800

 --
  .../form/AjaxFormComponentUpdatingBehavior.java |   2 +-
  .../wicket/core/util/string/CssUtils.java   |  14 ++
  .../markup/html/form/AutoLabelResolver.java | 130 ++-
  .../apache/wicket/markup/html/form/Form.java|  24 +++-
  .../wicket/markup/html/form/FormComponent.java  |  34 -
  .../wicket/protocol/http/WebApplication.java|  36 +++--
  6 files changed, 212 insertions(+), 28 deletions(-)
 --



 http://git-wip-us.apache.org/repos/asf/wicket/blob/a73209be/wicket-core/src/main/java/org/apache/wicket/ajax/form/AjaxFormComponentUpdatingBehavior.java
 --
 diff --git
 a/wicket-core/src/main/java/org/apache/wicket/ajax/form/AjaxFormComponentUpdatingBehavior.java
 b/wicket-core/src/main/java/org/apache/wicket/ajax/form/AjaxFormComponentUpdatingBehavior.java
 index 7eab478..bd8267c 100644
 ---
 a/wicket-core/src/main/java/org/apache/wicket/ajax/form/AjaxFormComponentUpdatingBehavior.java
 +++
 b/wicket-core/src/main/java/org/apache/wicket/ajax/form/AjaxFormComponentUpdatingBehavior.java
 @@ -160,8 +160,8 @@ public abstract class
 AjaxFormComponentUpdatingBehavior extends AjaxEventBehavio
 catch (RuntimeException e)
 {
 onError(target, e);
 -
 }
 +   formComponent.updateAutoLabels(target);
 }

 /**


 http://git-wip-us.apache.org/repos/asf/wicket/blob/a73209be/wicket-core/src/main/java/org/apache/wicket/core/util/string/CssUtils.java
 --
 diff --git
 a/wicket-core/src/main/java/org/apache/wicket/core/util/string/CssUtils.java
 b/wicket-core/src/main/java/org/apache/wicket/core/util/string/CssUtils.java
 index a4944a3..7de8669 100644
 ---
 a/wicket-core/src/main/java/org/apache/wicket/core/util/string/CssUtils.java
 +++
 b/wicket-core/src/main/java/org/apache/wicket/core/util/string/CssUtils.java
 @@ -103,4 +103,18 @@ public final class CssUtils
 }
 response.write( /);
 }
 +
 +   /**
 +* Get a standardized key for a CSS class.
 +*
 +* @param scope
 +*scope of CSS class
 +* @param facet
 +*facet of CSS class
 +* @return CSS key
 +*/
 +   public static String key(Class? scope, String facet)
 +   {
 +   return scope.getSimpleName() + .CSS. + facet;
 +   }
  }


 http://git-wip-us.apache.org/repos/asf/wicket/blob/a73209be/wicket-core/src/main/java/org/apache/wicket/markup/html/form/AutoLabelResolver.java
 --
 diff --git
 a/wicket-core/src/main/java/org/apache/wicket/markup/html/form/AutoLabelResolver.java
 b/wicket-core/src/main/java/org/apache/wicket/markup/html/form/AutoLabelResolver.java
 index 562e6ed..7892fa7 100644
 ---
 a/wicket-core/src/main/java/org/apache/wicket/markup/html/form/AutoLabelResolver.java
 +++
 b/wicket-core/src/main/java/org/apache/wicket/markup/html/form/AutoLabelResolver.java
 @@ -16,9 +16,14 @@
   */
  package org.apache.wicket.markup.html.form;

 +import java.io.Serializable;
 +
  import org.apache.wicket.Component;
  import org.apache.wicket.MarkupContainer;
 +import org.apache.wicket.MetaDataKey;
  import org.apache.wicket.WicketRuntimeException;
 +import org.apache.wicket.ajax.AjaxRequestTarget;
 +import org.apache.wicket.core.util.string.CssUtils;
  import org.apache.wicket.markup.ComponentTag;
  import org.apache.wicket.markup.MarkupStream;
  import org.apache.wicket.markup.html.TransparentWebMarkupContainer;
 @@ -36,11 +41,14 @@ import org.slf4j.LoggerFactory;
   * liOutputs the {@code for} attribute with the value equivalent to the
 markup id of the
   * referenced form component/li

Re: Eclipse formatting, was: Martin's wicket pull request

2013-11-09 Thread Igor Vaynberg

yes, making it a workspace default messes up other projects...

this way every time i import a project into the eclipse workspace i
have to go and manually set the formatter on every module, which as
you can imagine is not optimal

-igor

On Sat, Nov 9, 2013 at 1:40 PM, Martin Grigorov mgrigo...@apache.org wrote:
 But you have to import the xml just once, right ? It is not a big deal.
 Or the problem is that the xml messes up the other projects in your
 workspace ?



 On Sat, Nov 9, 2013 at 7:24 AM, Igor Vaynberg igor.vaynb...@gmail.comwrote:

 it is really frustrating that i have to do this manually now. before
 all i had to do was checkout the project and it was all set. wicket
 shares my workspace with other projects so the workspace-default is
 not going to work.

 can we drop the format def on wicket.apache.org and configure the
 maven plugin to set it up:

 http://maven.apache.org/plugins/maven-eclipse-plugin/examples/load-code-styles.html

 -igor

 On Fri, Nov 8, 2013 at 12:56 AM, Martin Grigorov mgrigo...@apache.org
 wrote:
  I'll test this soon.
  I'll update the docs for IDEA too if needed.
 
 
  On Thu, Nov 7, 2013 at 11:02 AM, Sven Meier s...@meiers.net wrote:
 
  Thanks, I've added a hint to the Idea instructions.
 
  Regards
  Sven
 
 
  On 11/06/2013 10:12 AM, Vojtěch Krása wrote:
 
  You should also specify values for Class count to use import with '*'
  and
  Names count to use static import with '*', since these values are
  not in EclipseCodeFormat.xml,
  and differs between Idea and Eclipse by default.
 
 
  V.
 
 
  2013/11/6 Sven Meier s...@meiers.net
 
   Hi all,
 
  I removed all org.eclipse.jdt.[core|ui].prefs from the repo as
  discussed.
  EclipseCodeFormat.xml is updated now to our latest and greatest code
  format
  (which might differ between 6.x and master).
 
  Eclipse users should run mvn eclipse:eclipse to regenerate
  org.eclipse.jdt.core.prefs, then (re-)import EclipseCodeFormat.xml and
  use
  it as the default for your Wicket workspace(s).
  I've added a paragraph about the recommended Eclipse setup here:
  http://wicket.apache.org/learn/ides.html
 
  Could an Idea user please confirm that the format plugin (
  http://plugins.jetbrains.com/plugin/6546) works as expected?
 
  Regards
  Sven
 
  On 11/05/2013 12:05 PM, Martin Grigorov wrote:
 
   On Tue, Nov 5, 2013 at 1:01 PM, Sven Meier s...@meiers.net wrote:
 
IMHO we should have one authoritative source for our source format
  only.
 
  Whether this is EclipseCodeFormat.xml or something else can be
 dicussed
  on
  the other mail thread.
 
  Currently all org.eclipse.jdt.core.prefs have already diverged from
  EclipseCodeFormat.xml (perhaps they even differ between each
 other?),
  so
  I'm +1 to remove those settings from the repo as Martin has
 suggested.
  I can live with having to configure my Wicket workspace(s) once by
  importing EclipseCodeFormat.xml.
 
  So if no one objects, I'll update EclipseCodeFormat.xml from the
  current
  settings in wicket-core and apply Martin's patch afterwards.
 
   I'm +1.
  With the plugin that Rusi suggested in the other thread I can import
 EclipseCodeFormat.xml in Intellij IDEA and hopefully the
 formatting
  will
  be the same for all of us.
 
 
 
   Sven
 
 
 
  On 11/04/2013 04:42 PM, Martin Funk wrote:
 
not quite
 
  if the org.eclipse.jdt.ui.prefs are not present eclipse will fall
 back
  to
  the workspace setting esp. formatter.
  The formatter profile as I described it in the attachment to
  https://issues.apache.org/jira/browse/WICKET-5399
  has to be imported into the workspace once.
  If one has to follow more than one code formatting rulesets, than
 they
  have to be set for each
  project. The setting of the formatter profile will be written to
  org.eclipse.jdt.ui.prefs.
 
  mf
 
  Am 04.11.2013 um 16:25 schrieb Sven Meier s...@meiers.net:
 
 Ok, removing org.eclipse.jdt.core.prefs and
  org.eclipse.jdt.ui.prefs
  is
 
   easy.
 
  But without these files the Eclipse project settings (Java Code
 Style
  -
  Formatter) have to be adjusted manually for each Wicket module
 after
  mvn
  eclipse:eclipse :(.
 
  Sven
 
  On 11/04/2013 09:58 AM, Martin Grigorov wrote:
 
Hi,
 
  Can someone of other Wicket code developers take a look at
  https://github.com/apache/wicket/pull/56 ?
  This is a pull request with some changes/updates to Eclipse's
  .settings/
  (required by newer versions of Eclipse ?!).
  I don't use Eclipse and I cannot decide whether the PR is good or
  not.
 
  https://github.com/apache/wicket/pull/57/commits is another PR
 from
  Martin
  Funk that has some improvements to Wicket's unit tests that I'd
 like
  to
  merge but I cannot because it depends on PR 56.
 
  Additionally I'd like to ask all Eclipse users to disable the
 auto
  format
  the whole file feature.
  https://github.com/mafulafunk/wicket/commit/
  0aac81f393047865088864c6b299ce1e022ce1fa
  (part
  of PR 57) has such formatting changes that we agreed should

[jira] [Created] (WICKET-5410) Remove setting interfaces

Igor Vaynberg created WICKET-5410:
-

 Summary: Remove setting interfaces
 Key: WICKET-5410
 URL: https://issues.apache.org/jira/browse/WICKET-5410
 Project: Wicket
  Issue Type: Improvement
Reporter: Igor Vaynberg
 Fix For: 7.0.0


We still have separate settings interfaces. mostly this is a legacy design 
decision when we have a single settings object implement all these interfaces.

the problem now that we are in semver is that we cannot add new settings in 
between major releases because doing so requires adding a method to an 
interface.

since we do not have a single class implementing multiple interfaces scenario 
anymore we can get rid of the settings interfaces safely.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Created] (WICKET-5411) Improve AutoLabels to update their CSS dynamically

Igor Vaynberg created WICKET-5411:
-

 Summary: Improve AutoLabels to update their CSS dynamically
 Key: WICKET-5411
 URL: https://issues.apache.org/jira/browse/WICKET-5411
 Project: Wicket
  Issue Type: Improvement
  Components: wicket
Reporter: Igor Vaynberg
Assignee: Igor Vaynberg
 Fix For: 7.0.0






--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Updated] (WICKET-5411) Improve AutoLabels to update their CSS dynamically


 [ 
https://issues.apache.org/jira/browse/WICKET-5411?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Igor Vaynberg updated WICKET-5411:
--

Fix Version/s: 6.13.0

 Improve AutoLabels to update their CSS dynamically
 --

 Key: WICKET-5411
 URL: https://issues.apache.org/jira/browse/WICKET-5411
 Project: Wicket
  Issue Type: Improvement
  Components: wicket
Reporter: Igor Vaynberg
Assignee: Igor Vaynberg
 Fix For: 6.13.0, 7.0.0






--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Updated] (WICKET-5411) Improve AutoLabels to update their CSS dynamically


 [ 
https://issues.apache.org/jira/browse/WICKET-5411?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Igor Vaynberg updated WICKET-5411:
--

Description: 
The problem with auto labels is that once they are rendered the only way to 
update their `error`/`required` css classes during ajax requests is to update 
some parent since auto components cannot be targeted directly. however, when 
dealing with forms we may not necessarily want to repaint components because we 
may lose state.

This issue solves the problem by tracking state changes in form components that 
have auto labels and updating their css classes on all ajax requests.

 Improve AutoLabels to update their CSS dynamically
 --

 Key: WICKET-5411
 URL: https://issues.apache.org/jira/browse/WICKET-5411
 Project: Wicket
  Issue Type: Improvement
  Components: wicket
Reporter: Igor Vaynberg
Assignee: Igor Vaynberg
 Fix For: 6.13.0, 7.0.0


 The problem with auto labels is that once they are rendered the only way to 
 update their `error`/`required` css classes during ajax requests is to update 
 some parent since auto components cannot be targeted directly. however, when 
 dealing with forms we may not necessarily want to repaint components because 
 we may lose state.
 This issue solves the problem by tracking state changes in form components 
 that have auto labels and updating their css classes on all ajax requests.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Updated] (WICKET-5411) Improve AutoLabels by updating their CSS classes automatically during Ajax requests


 [ 
https://issues.apache.org/jira/browse/WICKET-5411?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Igor Vaynberg updated WICKET-5411:
--

Summary: Improve AutoLabels by updating their CSS classes automatically 
during Ajax requests  (was: Improve AutoLabels to update their CSS dynamically)

 Improve AutoLabels by updating their CSS classes automatically during Ajax 
 requests
 ---

 Key: WICKET-5411
 URL: https://issues.apache.org/jira/browse/WICKET-5411
 Project: Wicket
  Issue Type: Improvement
  Components: wicket
Reporter: Igor Vaynberg
Assignee: Igor Vaynberg
 Fix For: 6.13.0, 7.0.0


 The problem with auto labels is that once they are rendered the only way to 
 update their `error`/`required` css classes during ajax requests is to update 
 some parent since auto components cannot be targeted directly. however, when 
 dealing with forms we may not necessarily want to repaint components because 
 we may lose state.
 This issue solves the problem by tracking state changes in form components 
 that have auto labels and updating their css classes on all ajax requests.
 disabled by default in 6.13, always enabled in 7.0



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Updated] (WICKET-5411) Improve AutoLabels to update their CSS dynamically


 [ 
https://issues.apache.org/jira/browse/WICKET-5411?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Igor Vaynberg updated WICKET-5411:
--

Description: 
The problem with auto labels is that once they are rendered the only way to 
update their `error`/`required` css classes during ajax requests is to update 
some parent since auto components cannot be targeted directly. however, when 
dealing with forms we may not necessarily want to repaint components because we 
may lose state.

This issue solves the problem by tracking state changes in form components that 
have auto labels and updating their css classes on all ajax requests.

disabled by default in 6.13, always enabled in 7.0

  was:
The problem with auto labels is that once they are rendered the only way to 
update their `error`/`required` css classes during ajax requests is to update 
some parent since auto components cannot be targeted directly. however, when 
dealing with forms we may not necessarily want to repaint components because we 
may lose state.

This issue solves the problem by tracking state changes in form components that 
have auto labels and updating their css classes on all ajax requests.


 Improve AutoLabels to update their CSS dynamically
 --

 Key: WICKET-5411
 URL: https://issues.apache.org/jira/browse/WICKET-5411
 Project: Wicket
  Issue Type: Improvement
  Components: wicket
Reporter: Igor Vaynberg
Assignee: Igor Vaynberg
 Fix For: 6.13.0, 7.0.0


 The problem with auto labels is that once they are rendered the only way to 
 update their `error`/`required` css classes during ajax requests is to update 
 some parent since auto components cannot be targeted directly. however, when 
 dealing with forms we may not necessarily want to repaint components because 
 we may lose state.
 This issue solves the problem by tracking state changes in form components 
 that have auto labels and updating their css classes on all ajax requests.
 disabled by default in 6.13, always enabled in 7.0



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Updated] (WICKET-5411) Improve AutoLabels by updating their CSS classes automatically during Ajax requests