Re: core devs cannot close PRs on github?

2015-03-12 Thread Martin Grigorov
Hi,

Yes. We don't have the permissions to do anything in the repositories.
GitHub repos are just mirrors of the official Apache Git repositories.
Only Apache Infrastructure team has write/admin rights there.
Many people from Apache projects have asked Infra team for better support
for Pull Requests in Apache.
At the moment this is the best solution they provide us :-/
We can pull your PRs from GitHub into Apache Git and if everything is done
the Git way then the PR is closed automatically. But if there is
something manual in the applying process then the automatic tool doesn't
work and we have to ask either the reporter to close the PR or Apache
Infra...

Martin Grigorov
Funemployed! Available for hire!
Wicket Training and Consulting
https://twitter.com/mtgrigorov

On Thu, Mar 12, 2015 at 10:54 AM, Thibault Kruse tibokr...@googlemail.com
wrote:

 Hi,

 I notice that the core devs have to ask PR submitters to close their
 PRs on github:
 https://github.com/apache/wicket/pull/101

 I am curious: Why is that so?

 Looking here:

 https://help.github.com/articles/permission-levels-for-an-organization-repository/

 I assume the wicket core devs are only part of a read access team,
 not a write access team within the github apache organisation. But
 why would Apache do it like that, given teams can be granted
 permissions on a per-repository basis?


 regards,
   Thibault

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




core devs cannot close PRs on github?

2015-03-12 Thread Thibault Kruse
Hi,

I notice that the core devs have to ask PR submitters to close their
PRs on github:
https://github.com/apache/wicket/pull/101

I am curious: Why is that so?

Looking here:
https://help.github.com/articles/permission-levels-for-an-organization-repository/

I assume the wicket core devs are only part of a read access team,
not a write access team within the github apache organisation. But
why would Apache do it like that, given teams can be granted
permissions on a per-repository basis?


regards,
  Thibault

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



Re: core devs cannot close PRs on github?

2015-03-12 Thread Martijn Dashorst
Yup. The integration between github and Apache are suboptimal. Infra
is aware of the issue and wants to work on it. I have no insights into
their plans, other than that they are in constant talks with github
employees to improve the integration. Infra has been busy upgrading
the services but they are way behind in work–ageing and failing
hardware being the biggest hurdle.

The reason Apache needs its own server is one of ensuring that the
code coming in is actually from someone who is allowed to do so.
Apache has no knowledge who is actually behind a github account, so we
can't just import the code directly. Also the canonical code needs to
be on ASF controlled hardware to ensure nobody else has write access
to it (and could rewrite history).

So for now it sucks, but things will improve somewhere this year (not
saying it is an Earth year :-)

Martijn



On Thu, Mar 12, 2015 at 9:54 AM, Thibault Kruse
tibokr...@googlemail.com wrote:
 Hi,

 I notice that the core devs have to ask PR submitters to close their
 PRs on github:
 https://github.com/apache/wicket/pull/101

 I am curious: Why is that so?

 Looking here:
 https://help.github.com/articles/permission-levels-for-an-organization-repository/

 I assume the wicket core devs are only part of a read access team,
 not a write access team within the github apache organisation. But
 why would Apache do it like that, given teams can be granted
 permissions on a per-repository basis?


 regards,
   Thibault

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




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

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



RE: New committer - Sebastien Briquet

2015-03-12 Thread Colin Rogers
Only just saw this... well done Sebastien - you've always been amazing help 
with JQuery-UI :)

-Original Message-
From: Patrick Davids [mailto:patrick.dav...@nubologic.com]
Sent: Monday, 16 February 2015 7:05 PM
To: users@wicket.apache.org
Subject: Re: New committer - Sebastien Briquet

Yeah, congratulations Sebastien!
:-)

Am 13.02.2015 um 22:02 schrieb Martin Grigorov:
 The Project Management Committee (PMC) for Apache Wicket has asked
 Sebastien Briquet to become a committer and we are pleased to announce
 that he has accepted.

 Sebastien has been involved with Wicket for several years now by
 developing one of the most successful integrations with JavaScript
 libraries, namely Wicket jQuery UI
 https://github.com/sebfz1/wicket-jquery-ui, reporting bugs,
 contributing fixes and participating in discussions.

 Being a committer will enable him to help us even easier in the future.

 Please welcome Sebastien Briquet to our team!

 Bienvenue Sebastien!



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

EMAIL DISCLAIMER This email message and its attachments are confidential and 
may also contain copyright or privileged material. If you are not the intended 
recipient, you may not forward the email or disclose or use the information 
contained in it. If you have received this email message in error, please 
advise the sender immediately by replying to this email and delete the message 
and any associated attachments. Any views, opinions, conclusions, advice or 
statements expressed in this email message are those of the individual sender 
and should not be relied upon as the considered view, opinion, conclusions, 
advice or statement of this company except where the sender expressly, and with 
authority, states them to be the considered view, opinion, conclusions, advice 
or statement of this company. Every care is taken but we recommend that you 
scan any attachments for viruses.

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



Accessing PageParameters within Panel

2015-03-12 Thread David Kaufman
Hi,

I'm currently migrating a fairly large project from wicket 1.4 to wicket 6.

We're currently getting the PageParameters from the RequestCycle
via getRequestCycle().getPageParameters(), with wicket 6 this is no longer
possible. Getting the PageParameters via getPage().getPageParameters() is a
viable option but I'm not quite sure if this is the way to go. Another way
of getting parameters is by calling getRequest().getQueryParameters() but
I'm also not sure if these are identical with the PageParameters (they are
differently typed so I suspect that they are inherently different).

Thanks,
David


Re: Accessing PageParameters within Panel

2015-03-12 Thread Tobias Soloschenko
Hi,

https://cwiki.apache.org/confluence/display/WICKET/Migration+to+Wicket+1.5

Search for Request parameters

kind regards

Tobias

 Am 12.03.2015 um 17:20 schrieb David Kaufman david.kauf...@gmx.de:
 
 Hi,
 
 I'm currently migrating a fairly large project from wicket 1.4 to wicket 6.
 
 We're currently getting the PageParameters from the RequestCycle
 via getRequestCycle().getPageParameters(), with wicket 6 this is no longer
 possible. Getting the PageParameters via getPage().getPageParameters() is a
 viable option but I'm not quite sure if this is the way to go. Another way
 of getting parameters is by calling getRequest().getQueryParameters() but
 I'm also not sure if these are identical with the PageParameters (they are
 differently typed so I suspect that they are inherently different).
 
 Thanks,
 David

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



Re: Accessing PageParameters within Panel

2015-03-12 Thread Martin Grigorov
Hi,

getPage().getPageParameters() returns the GET parameters at the time the
page has been created.
If the page is stateful and you submit a form, or click a link (normal and
Ajax ones) then you need getRequest().get***Parameters().

Martin Grigorov
Freelancer, available for hire!
Wicket Training and Consulting
https://twitter.com/mtgrigorov

On Thu, Mar 12, 2015 at 6:20 PM, David Kaufman david.kauf...@gmx.de wrote:

 Hi,

 I'm currently migrating a fairly large project from wicket 1.4 to wicket 6.

 We're currently getting the PageParameters from the RequestCycle
 via getRequestCycle().getPageParameters(), with wicket 6 this is no longer
 possible. Getting the PageParameters via getPage().getPageParameters() is a
 viable option but I'm not quite sure if this is the way to go. Another way
 of getting parameters is by calling getRequest().getQueryParameters() but
 I'm also not sure if these are identical with the PageParameters (they are
 differently typed so I suspect that they are inherently different).

 Thanks,
 David



Re: Help for Apache Wicket HiddenField

2015-03-12 Thread Sebastien
Hi Sergio,

In certain scenarii, CPM  can misslead [1]. This could be the case here as
you only have compound component(s). But to be sure, use a propertymodel
as the hiddentextfield's model and see if it works better...

Alternatively, you can ensure your object is not changed/recreated. Put an
access breakpoint to ensure someClassObj does not change in between...

Hope this helps,
Sebastien.

[1] ie: https://issues.apache.org/jira/browse/WICKET-5792


On Thu, Mar 12, 2015 at 5:59 PM, Sergio Arellano Ruiz sergio.r...@hcl.com
wrote:

 Hi, im currently having some issues with a CompoundPropertyModel and
 HiddenField. I'm trying to relate the property of the model with the hidden
 input field value. I'm not sure if this actually make sense (probably
 doesn't), anyway the problem I'm facing is the model is not getting updated
 with the input value. So I'm wondering if what im trying to do it actually
 make sense and if it is possible. I'll add some instance code.

 PD: Wicket is love!.

 Thank you,
 Sergio Arellano.

 Instanse code used:

 //the bean of the model
 class SomeClass{
 String attr1;
 Int attr2;
 // more  code
 }

 //the form (it is used inside a wicket:panel component)
 SomeClass someClassObj = new SomeClass();
 private Form SomeClass  newSomeClassForm() {
 CompoundPropertyModel SomeClass  someClassModel = new
 CompoundPropertyModel SomeClass (someClassObj);
 Form SomeClass  someClassForm = new Form SomeClass ( someClassForm ,
 someClassModel);
 //here the other bean attrributes
 someClassForm.add(newSaveButton());
 HiddenField attr1 = new HiddenField(attr1);
 someClassForm.add(attr1);
 return someClassForm;
 }

 private AjaxButton newSaveButton() {
 return new AjaxButton(btnSave ) {

 @Override
 protected void onSubmit(AjaxRequestTarget target, Form?
 form) {
 //here im getting null value for the input property
 System.out.println(attr1:  + someClassObj.attr1);
 }

 };
 }

 //the html
 form wicket:id= someClassForm 
 label wicket:id=lblSomeLabel[some label text]/label
 input wicket:id=btnSave type=button
 value=save/input
 input wicket:id= attr1 type=hidden
 value=1555/input
 /form


 ::DISCLAIMER::

 

 The contents of this e-mail and any attachment(s) are confidential and
 intended for the named recipient(s) only.
 E-mail transmission is not guaranteed to be secure or error-free as
 information could be intercepted, corrupted,
 lost, destroyed, arrive late or incomplete, or may contain viruses in
 transmission. The e mail and its contents
 (with or without referred errors) shall therefore not attach any liability
 on the originator or HCL or its affiliates.
 Views or opinions, if any, presented in this email are solely those of the
 author and may not necessarily reflect the
 views or opinions of HCL or its affiliates. Any form of reproduction,
 dissemination, copying, disclosure, modification,
 distribution and / or publication of this message without the prior
 written consent of authorized representative of
 HCL is strictly prohibited. If you have received this email in error
 please delete it and notify the sender immediately.
 Before opening any email and/or attachments, please check them for viruses
 and other defects.


 



Help for Apache Wicket HiddenField

2015-03-12 Thread Sergio Arellano Ruiz
Hi, im currently having some issues with a CompoundPropertyModel and 
HiddenField. I'm trying to relate the property of the model with the hidden 
input field value. I'm not sure if this actually make sense (probably doesn't), 
anyway the problem I'm facing is the model is not getting updated with the 
input value. So I'm wondering if what im trying to do it actually make sense 
and if it is possible. I'll add some instance code.

PD: Wicket is love!.

Thank you,
Sergio Arellano.

Instanse code used:

//the bean of the model
class SomeClass{
String attr1;
Int attr2;
// more  code
}

//the form (it is used inside a wicket:panel component)
SomeClass someClassObj = new SomeClass();
private Form SomeClass  newSomeClassForm() {
CompoundPropertyModel SomeClass  someClassModel = new CompoundPropertyModel 
SomeClass (someClassObj);
Form SomeClass  someClassForm = new Form SomeClass ( someClassForm , 
someClassModel);
//here the other bean attrributes
someClassForm.add(newSaveButton());
HiddenField attr1 = new HiddenField(attr1);
someClassForm.add(attr1);
return someClassForm;
}

private AjaxButton newSaveButton() {
return new AjaxButton(btnSave ) {

@Override
protected void onSubmit(AjaxRequestTarget target, Form? form) {
//here im getting null value for the input property
System.out.println(attr1:  + someClassObj.attr1);
}

};
}

//the html
form wicket:id= someClassForm 
label wicket:id=lblSomeLabel[some label text]/label
input wicket:id=btnSave type=button value=save/input
input wicket:id= attr1 type=hidden value=1555/input
/form


::DISCLAIMER::


The contents of this e-mail and any attachment(s) are confidential and intended 
for the named recipient(s) only.
E-mail transmission is not guaranteed to be secure or error-free as information 
could be intercepted, corrupted,
lost, destroyed, arrive late or incomplete, or may contain viruses in 
transmission. The e mail and its contents
(with or without referred errors) shall therefore not attach any liability on 
the originator or HCL or its affiliates.
Views or opinions, if any, presented in this email are solely those of the 
author and may not necessarily reflect the
views or opinions of HCL or its affiliates. Any form of reproduction, 
dissemination, copying, disclosure, modification,
distribution and / or publication of this message without the prior written 
consent of authorized representative of
HCL is strictly prohibited. If you have received this email in error please 
delete it and notify the sender immediately.
Before opening any email and/or attachments, please check them for viruses and 
other defects.